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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
