alternative/leaner installer creation algorithm: GSoC idea?

[René J.V. Bertin]

On Saturday May 13 2017 16:03:59 Craig Treleaven wrote:

>> That is also inherent to the fact that Qt4 is installed as a monolithic port, not split in the different Qt components as port:qt5 is.
>> 
>That horse is long gone from the barn.  Anyway, my MythTV packages didn’t get much smaller when it moved to Qt5.  I need to bring in a lot of the big components of Qt5 regardless.  Maybe rwkward’s needs are different.

That's one reason why I've never considered breaking up my port:qt5-kde that will be the preferred dependency for the KF5 ports, at least not beyond the split-off of QtWebKit and QtWebEngine + the latter's dependents. The brunt of the rest comes from Qt components that most applications need anyway.

>That’s not what I meant.  Simply rm’ing components is going to leave something broken.  Whether they like it not, they are shipping a complete KDE desktop environment* with rwkward.  I would guess that they’ve broken the soprano->strigi search tools.

A complete DE, are you sure? That includes a bit more than just KDElibs4. EIther way, if they remove the FFmpeg plugin from strigi you lose just the functionality to search/index multimedia files, which is not a problem at all if the only KDE application you have (or are aware of) has no use for that.
I'm not even certain if KDE4 still really uses soprano and strigi in its latest version. Neither of them has made it to KF5 to my knowledge.

>  If that is true, we add an ffmpeg variant to strigi and make it the default.

Sure, but that's presuming that the strigi maintainer agrees with the request and accepts to implement it for something s/he may have no affinity with at all. Alternatively the person doing the packaging could start maintaining his or her own forked ports. Two faces of a situation I'm quite familiar with...
An effort to improve the packaging functionality so it becomes easier to create lean installers would benefit everyone with putting the burden on the shoulder of port maintainers, possibly even the person (student) who gets to implement it.

>I don’t know what the state is with KDE and X11 but if it will work OK with a Quartz variant, I believe that chops the size down very substantially.

KDE4 works only with Cocoa because Qt4 cannot be built for X11 anymore since 4.6 or so.

>*BTW, why does rwkward need KDE?  Qt makes it possible to develop an application that runs natively on Linux, Mac, Windows and elsewhere.  If they’re serious about reducing the bloat, they could make a huge leap by using only Qt’s facilities!

KDE adds a lot of useful features to Qt. RKWard hasn't quite tried to minimise the number of frameworks required in its KF5 incarnation. That makes sense if their main targeted platform is the KDE/Plasma desktop where those frameworks are all available anyway, and it allows to keep the application sources small and to focus on their real goal. RKWard is a KDE application, the only bloat KDE stuff could add would come from unused libraries, and those should be pruned by the move to KF5.

R.