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

[Jordan K. Hubbard]

On Sep 20, 2010, at 2:13 PM, Jeremy Lavergne wrote:

>> 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).
> 
> The user is not installing them. MacPorts does.  Please review the source code of MacPorts for the archive and unarchive phases.
> [ ... ]
> BTW, you'll find these files in the archives that are generated.
> 
> +COMMENT
> +CONTENTS
> +DESC
> +PORTFILE
> +STATE
> 
> So once again, since MacPorts calls them archives, even though they're packages in teh sense you discussed, they cover the needs here.

So, I was familiar with this code before, but just on the off-chance that it increased in capability lately, I went looking at it again.  Nope, still a smart extractor, basically.  It handles everything from tarballs to xar archives, which is great, but the telling part of package1.0/portunarchive.tcl is in the function unarchive_finish - all it ever does with the "control files" you mention is delete them.  It never opens them or acts on their contents, so I really don't see how they CAN be package files in the sense I discussed.

If, by contrast, we refer to the FreeBSD package manager source code in /usr/src/usr.sbin/pkg_install/add (I trust you have access to the FreeBSD source tree somewhere), we will see two files:  extract.c and perform.c.  What has been written in MacPorts is the equivalent of extract.c - it extracts the archive into some location.  What you are missing is the logic in perform.c to actually act on the +CONTENTS file - I know what it looks like since I wrote that ugly mess (but hey, it works). :-)

> Right, so this is a giant semantics issue. Arguably, MacPorts is not built to do "packages"--ever.  Time for a new project, or we can sit on our hands and not use archives either.

Actually, I would argue the opposite:  MacPorts is in an excellent position to make packages and has an enviable collection of recipes and other metadata necessary to make some really nice ones.  What it simply lacks is the discipline to say "OK, from this day forward, MacPorts does not install software ever.  Ever ever EVAR!   We'll just build stuff and make the installation of it the problem of a new layer of software we now have to write."

If you add up all of the lines of code in MacPorts so far, in fact, it becomes very clear that the bulk of it really is a software BUILD system, not a software INSTALLATION system - that latter part is actually something of a hack that MacPorts would probably benefit substantially from being able to remove.   I'm not saying that nobody would ever be able to install software in my perfect universe - that would obviously be pointless and lame - I'm just saying that there are some parts where the problem lends itself very well to being broken into distinct pieces, and having one distinct piece take over the challenge of building software in a reproducible way, isolated as much as possible from the build host, and another piece take on the challenge of actually permuting the target system in a secure, undoable way, buys you a very clean demarkation point from the perspective of security, fault isolation and so on.

>> 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. :(
> 
> I'm not going to keep defining "package" versus "archive". MacPorts' functionality allows it to download binaries and install them.  No hours of building. Please stop beating the semantics horse over how I titled what it does.

Huh?  There's no semantic quibbling there at all.  I simply said you did not have build success/failure logs there, which is what my original question was about.  You are the one changing the subject here, not me. :-)   I also believe, though it has nothing to do with logging, that there IS a very definite distinction between archives and packages right now in MacPorts, particularly given that archives are not doing anything with the metadata yet (c.f. above discussion with respect to extract vs perform).

- Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20100920/3cf59cb6/attachment-0001.html>