alternative/leaner installer creation algorithm: GSoC idea?

[Rainer Müller]

On 2017-05-13 16:38, René J.V. Bertin wrote:
> I *think* that `port mpkg foo` will build all of foo's dependencies with their default variant and/or variants they share with foo. For instance, rkward depends on R with by default installs with +x11 and +builtin_lapack; that's what you'll probably get in the pkg. Rkward will work just fine though without X11 support in R and with +accelerate, which should decrease R's size and get rid of most if not all X11 stuff. By reverse-engineering rkward's (foo's) port dependencies and bundling the ones that are actually installed you should have a better chance to create a snapshot of what you have installed.

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

Both are not perfect, but should be a solution until we can declare
dependencies on variants.

> You also get the actual dependencies, without any dependencies that port maintainers declared as depends_lib instead of depends_build ... and evidently also dependencies that somehow were missed.

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
binary archives would also benefit from this.
> How much difference it really makes remains to be seen in practice, but you should at least lose the depends_build ones if they are currently being included.

'port mpkpg' only includes depends_run and depends_lib already.

https://github.com/macports/macports-base/blob/e0c7f1c/src/package1.0/portmpkg.tcl#L85-L88

> I'm not perfectly certain about the handling of runtime dependencies either. Maybe it should be left to the operator to decide which to include, based on a list presented when invoking the package command with `-vy`; in that case it should be possible to list multiple ports for packaging into a single pkg with a single command.
Sounds reasonable, .mpkg is just a couple of .pkg with a XML description
in the "Distribution" file. You could create your own .mpkg based on
multiple .pkg already or even thin an existing .mpkg with pkgutil
--expand/--flatten.

'port mpkg' could be extended with a special mode that takes a list of
ports to include instead of scanning dependencies. Or that could be a
new command. Making that interactive based on the port dependencies
could then be the next step.

Rainer