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

[Jeremy Lavergne]

Clearly we're having a semantics issue here. MacPorts names them archives: please review how they're actually handled.

>>> 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. ...
> 
> 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).

The user is not installing them. MacPorts does.  Please review the source code of MacPorts for the archive and unarchive phases.

>> 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).

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.

>>> 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. :(

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20100920/9e4b6cfc/attachment.bin>