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

[Anders F Björklund]

Jordan K. Hubbard wrote:

>>> You're a long way from binary packages with just archives alone,  
>>> I'm afraid. :(
>>
>> Archives include the build folder, and the Portfile. To say we'd  
>> ruin people with archives you'd have to also agree we already ruin  
>> people with the way we run MacPorts entirely.
>
> Please don't confuse passive data with active data.  Sure, the  
> archives can and do include the original "port" metadata, but they  
> don't actually include the "package" metadata necessary to make  
> that port work stand-alone in the absence of macports (which,  
> again, is a goal here since macports drags in an entire devtools  
> suite and still puts the burden of building some amount of software  
> on the user).

The necessary metadata could easily be added to the archive metadata  
files, in a format similar to FreeBSD's. Based on your input even the  
old xar-based xpkg format was revived, to make it possible to add  
structured metadata (XML) rather than just tar/txt...

But since nobody is using it, it's just dumping some basic metadata  
(name, version etc) and a copy of the Portfile "just in case". The  
main contents would be the build state and the destroot, so it is  
only intended to help caching rather than for packaging.

> That part is either not been done, or done in a limited way for a  
> few popular package formats like .pkg, .rpm and .deb (though some  
> of those package formats have bitrotted some and probably need  
> updating).  This translation code between "port metadata" and  
> "package metadata"  is limited since it only knows how to translate  
> a certain number of runtime actions, like foo depends on bar, or  
> foo/blah should be installed with certain permissions, it doesn't  
> know how to translate the actual post-installation actions that  
> many ports have inside those Portfiles.   That is why those package  
> targets have largely bitrotted - they only do the job for a certain  
> subset of the ports collection and nobody quite finished them all  
> the way such that all ports could be truly packageable.

The .rpm was intended to be used internally, just like .deb are being  
used in the Fink project. So that each install/upgrade action would  
first build a package, and then install said package. The furthest  
attempt so far was in the "dp-lite" branch. As I see it, it (internal  
packages) was rejected - in favor of just using port archives.

The pkg/mpkg/dmg should still "work", but they only export things for  
use outside of MacPorts and lack interesting runtime options (and  
data). And since they are not Open Source either, it seems like a  
poor choice for a packaging format for MacPorts ? Besides the missing  
uninstall and lzma compression and all the other shortcomings, that is.

> I also never said we were "ruining" people, I simply said that if  
> you were already required to install MacPorts itself (the  
> infrastructure and ports files) then you are providing MacPorts,  
> same as always, and not a public package collection.  Just making  
> the archives available is more of an optimization which the project  
> could, someday, offer to its users as a way of skipping some of the  
> build process for certain popular projects, but they're still going  
> to be calling out to the compiler toolchain and still rebuilding  
> anything that a set of custom variants have been specified for  
> (since you won't have the right "canned archive" available) so it's  
> just an optimization, it's nothing particularly new or innovative.

That was the decision... Always require MacPorts (base), Developer  
Tools and the entire Ports tree too. And indirectly also always  
require Terminal, since no free GUI was completed.

> I'm still waiting for something new, like an actual package  
> collection which does not require anything but a very minimal Tcl  
> runtime which is distributed in the packages itself, making those  
> packages genuinely stand-alone and worthy of the name.

The previous approach was for a "pkg" command, that would do mostly  
the same as "port -b", but *not* require the Developer Tools. i.e.  
Mac "pkg install" would be similar to BSD "pkg_add".

I'm not sure why the runtime has to be in the packages themselves, it  
seems less redundant to have a small "installer" program installation  
contain that ? But either way, it would have been a "MacPorts  
Developer" that would offer to build things from ports and a  
"MacPorts User" that would simply install pre-made archives. And for  
that to work better, archives would need some improvements (extra data).

I started on the pkg.tcl command, but stopped since MacPorts was  
getting rewritten in Objective-C and SQLite anyway and there were no  
pre-built archives ("remotearchiveurl" *) available...

* http://trac.macports.org/ticket/8571

--anders