alternative/leaner installer creation algorithm: GSoC idea?

[Rainer Müller]

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.

> 6- bundle those ports from the current install.

Side note: please do not create and distribute .pkg installers for
/opt/local. That will inherently cause conflicts with a regular MacPorts
installation.

> Bundling could then use the software images of the final ports list but could also just scrape all their installed files into a new archive. If using the software images it should be possible to create an installer that installs those into an existing MacPorts installation if one is present (they're the same kind of images you get from the build bots).

Isn't the whole point of creating installers to be able to install
software without a full MacPorts installation? If you already have a
MacPorts installation, why not just use that? If I installed such a
software image without MacPorts and then later want to install MacPorts
this will not work out.

There once was the idea to include a minified version of MacPorts inside
the .pkg to be able to execute the Portfile for post-activate hooks and
register it ad-hoc in the registry without a full MacPorts installation
(back in the DarwinPorts days, dp-lite) However, this was abandoned
because just getting the essential parts was  not possible as there is
too much complexity.

Rainer