alternative/leaner installer creation algorithm: GSoC idea?

[René J.V. Bertin]

Hello,

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.

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
6- bundle those ports from the current install.

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

 Am I overlooking anything obvious in this approach?

R.