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

[Ryan Schmidt]

On Sep 20, 2010, at 16:07, Jordan K. Hubbard wrote:

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

I have been interested in binary packages but have not really understood how people wanted to do it, so this thread is instructive to me.

I had assumed that this "tool" you talk about being run would be MacPorts: the port command: "sudo port install foo", that it would just be enhanced to be able to download pre-compiled binaries that matched the OS, architecture and variants the user requested, if such existed on our hypothetical binaries server, and if not, it would build from source as it always has so far.


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

I had no idea there was a goal for users not to have MacPorts installed.

We just recently added the hard requirement in the MacPorts installer that Xcode be installed, since not having Xcode installed was causing so many various bug reports. But if MacPorts gets a binaries server, and the ability to download and install from it, that requirement could be relaxed and the check moved into the port command in such the port command only errors out and notifies the user Xcode is required if a binary package matching the user's request was not found.

I'm unsure why we wouldn't want a user to install MacPorts, if they want the software provided by MacPorts. Why should we invent a whole new system for installing software built by MacPorts? Why isn't MacPorts itself sufficient for that task?