alternative/leaner installer creation algorithm: GSoC idea?

[Craig Treleaven]

> On May 13, 2017, at 1:11 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> <Quoting levels are messed up, but whatever…>
> On Saturday May 13 2017 11:06:37 Craig Treleaven wrote:
> 
>> Indeed.  I presume it is the expanded installer payload that is 2 GB.  For me, a 330 MB installer expands to just over 1 GB on a destination system.
> 
> Actually, I misquoted, but we *were* talking about the size of the installer, not the installed footprint. The MacPorts installers and the corresponding installers for MS Windows:
> https://download.kde.org/stable/rkward/0.6.5/mac/
> https://download.kde.org/stable/rkward/0.6.5/win32/
> 
> 
> The latter is much smaller (why the sources are too is not clear).
> 
> 
>> Regarding rwkward, I notice that both gtk2 and gtk3 show up in rdeps.  Is there any opportunity to eliminate one?  I haven’t tried to figure out why both are being included.
> 
> Possibly, I've noticed before that (some) KDE4 ports lead to the installation of GtK which seems odd. I can't remember how that came to be.
> 
>> As I recall, a standalone installer for Qt4 alone was 150 MB and expanded to 0.5 GB by itself.
> 
> 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.

>> Once you’ve got an initial build of the installer, there are a couple of ways to look at the size of each of the component packages.  That may help find the best opportunities for trimming out redundant or unneeded bits.
> 
> That's what they already do, apparently, with dependencies like FFmpeg.
> 
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.

What I was suggesting was trying to use the component sizes to see if there where some big wins available with little effort.  In my example, some of the deps were bringing in mysql55 (or 56, I forget) where I already wanted to use MariaDB 5.5.  By forcing the mariadb variants, the installer was reduced by somehere around 55 MB.  Big win; dead simple.

> If we're talking about extending the command syntax, it might be possible also to add an --exclude-ports= argument to list ports you know to be redundant.
> 
> My algorithm might also allow yet another solution. Initially I thought one would fetch the ports list based on the generated binary dependency list, and include the entire ports. But MacPorts knows which files of a port are binaries, so it should be safe to remove at least all libraries that are not on that dependency list and aren't dependencies of port executables either. With the strigi example that would remove the dependency on FFmpeg.
> 
> BTW, I think we overlooked a difference earlier. My algorithm will not consider plugins in dependencies of the target port. That may be an issue in itself (requiring a list of files that need to be included?) but it does mean that KDELibs4's dependency on strigi would not pull in FFmpeg anyway because strigi's dependency on FFmpeg is through a plugin.
> 
> I knew it, something that looks simple enough at breakfast is likely to take on quite different proportions by dinner time :)
> 
Trying to bolt on new features to include or exclude ports at the packaging phase seems completely redundant to me.  We have an existing system for variants that works to produce sane builds with different configurations.  If strigi is including ffmpeg as a plugin, it seems likely that there is a way to build it excluding ffmpeg.  If that is true, we add an ffmpeg variant to strigi and make it the default.  Then when rwkward is being packaged, ask for the -ffmpeg variant and the result should be a sane build that is considerably smaller.  (I see the ffmpeg binary archive is about 42 MB.)  

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.

Craig

*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!