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
