alternative/leaner installer creation algorithm: GSoC idea?

[Craig Treleaven]

> On May 13, 2017, at 9:41 AM, Rainer Müller <raimue at macports.org> wrote:
> 
> On 2017-05-13 10:24, René J.V. Bertin wrote:
>> In an exchange with the port:rkward maintainer the subject came up that MacPorts creates huge packages if you use the installer-creation feature to generate a standalone installer for a port. I already noticed that myself but never went all the way for more complex ports because that would (apparently) require building every possible dependency from source. From what I understand, a "full" installer for port:rkward weighs in at almost 2Gb and includes things like FFmpeg that appear of somewhat unlikely use for a statistics package.
> 
> Hm, but everyone will get this many dependencies when they do the
> regular 'sudo port install rkward'. Why would this only be a specific
> problem for .pkg distribution?
> 
>> So there are 2 issues here:
>> - package size caused by including each and every possible dependency "down the tree"
>> - package creation time and required resources.
>> 
>> I doubt I'm the 1st to give these issues some thought but here's a brief outline of what I think might be possible as an alternative algorithm - and a nice GSoC or similar project. It's inspired by the rev-upgrade feature and should be able to use the information and functions already used by that feature:
>> 
>> 1- list all the target port's binaries
>> 2- fetch the recursive list of the actual dependencies of those binaries
>> 3- build the list of corresponding ports
>> 4- build the list of all runtime dependencies
>> 5- repeat steps 1-3 for all of these that aren't already in the current list of ports to install
> 
> Maybe I am missing something, but wouldn't you end up with the exact
> same list of ports by following depends_lib/depends_run as it is done
> now? In which case do you expect a difference with your algorithm?
> 
> Taking your example above, you would still go from rkward to kdelibs4 to
> strigi to ffmpeg.
> 
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.

Selecting existing variants judiously can help trim the installer.  For example, when I package mythtv.28, I specify:

sudo port mpkg mythtv.28 -x11+mariadb+mariadb55+python27+perl5_24+startupitem

Without that, I’ll get a bunch of unneeded X11 deps, one or more versions of MySQL, and python34.  I’d like to be able to get just one of db44, db46 and db48 but It seems that involves a non-trivial amount of work to other ports.  (IOW I’m too lazy to bother!)

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.

Nonetheless, given that rwkward relies on so much infrastructure that doesn’t exist on OS X by default, the installer and it’s payload are always going to be pretty large.  As I recall, a standalone installer for Qt4 alone was 150 MB and expanded to 0.5 GB by itself.  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.

Craig