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