alternative/leaner installer creation algorithm: GSoC idea?

[René J.V. Bertin]

On Saturday May 13 2017 17:02:33 Rainer Müller wrote:

> Hm, 'sudo port mpkg rkward -x11 +accelerate' on a clean prefix does not
> give you what you want? Variants would be passed down to dependencies
> that are not installed, just like with 'port install'.

Honestly, I don't know. I'm not about to try either with this kind of huge dependency list :)
I'd say you ought to bee right, though.

> If a dependency is meant to be depends_build, but is given in
> depends_lib, it would be an issue that needs to be resolved. Users of

True, but it can also be shorthand for depends_build+depends_run, and as I said, I'm not 100% certain that all runtime should always be included in a mpkg.

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.

> 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.

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 :)

R.