Packages Not [was Re: ambivalence about fortran (was Re: numpy & non-Apple gcc?)]

[Jordan K. Hubbard]

On Sep 20, 2010, at 1:44 PM, Jeremy Lavergne wrote:

>> 1. What process/script creates all the packages for all the ports?  Where is this documented?
> 
> Port does it itself, the archive and unarchive phases. The server-side scripts (don't forget autobuild project as well):
> https://trac.macports.org/wiki/archives

I'm sorry, but archives != packages, so in reality, the port(1) command is not creating packages in that scenario at all.  Archives are missing a bunch of the necessary metadata to quality as packages, the simplest example of which are deletes.  If you upgrade a port simply by extracting newer and newer archives, you will gradually accumulate cruft until such time as certain ports actual fail to work due to legacy bits being detected (and acted upon) when newer versions of the software were written with the assumption that those files were long gone.  You can potentially create a deletion list simply by "diffing" two archives, but that simply leaves you with the next bit of missing metadata, namely the files to explicitly migrate from version X to version X'.  There are also the post install actions to consider (add a role account user, run a special post-install script, etc) which archives do not provide.  Archives are essentially "dumb", and even the über-simplistic {Free,Net,Open}BSD package manager makes its .tar.gz package files "smarter" by including a special manifest file (+CONTENTS) that has a whole bunch of possible actions embedded in it.

You're a long way from binary packages with just archives alone, I'm afraid. :(

>> 2. The resulting packages are in what format?  .pkg?  .mpkg?  .deb?  .other?
> 
> tgz, tbz2, etc.
> You can create installers using pkg and dmg, but those are a different topic.

If we're discussing binary packages, they're really one and the same topic since you have to consider how the user is going to install them.   As we've just established, "tar --unlink -xpzf foopkg.tbz2 -C /" is just not going to cut it in providing a genuine installation experience for foopkg, so this implies a tool being run, either from the UI or CLI (preferably with options for both).

> Dependencies are handled just like any others:
> library and run deps are installed/built first. Since the binary distribution doesn't need the build_deps, they are skipped.  This is why I've had previously reported a lot of ports having their dependencies incorrect.

Again, you are assuming that the ports collection is installed and can build your deps.  That's not package management, that's the system we already have today and have had since day one (practically).  An actual package management solution would (and should) work in the absence of any macports installation since macports is really just for people operating the assembly line, it shouldn't be something end-users ever have to know or care about (or install DevTools in order to use).

>> 4. If you've been building all the ports since 1.9 came out, what's your fail/success rate right now?  Is this data being captured somewhere?
> 
> http://lavergne.gotdns.org/macports/

I must be missing something.  This seems to capture ticket data and allow you to browse a bunch of archives.  I'm not seeing any build fail/success logs for the individual ports, is what I meant.

In any case, no \o/ here so much as a /o\ since what you describe isn't packages yet or anything even really close. :(

- Jordan