[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-dev
Subject:    Re: alternative/leaner installer creation algorithm: GSoC idea?
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2017-05-13 20:57:28
Message-ID: 3901927.5ZvFaMOaBv () bola
[Download RAW message or body]

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.


[prev in list] [next in list] [prev in thread] [next in thread]