Universal and binary builds

[Jordan K. Hubbard]

On Mar 24, 2009, at 3:11 AM, Anders F Björklund wrote:

> Jordan K. Hubbard wrote:
>
>>> I guess I just don't see the appeal of rpm. What do you see as the  
>>> advantages of rpm?
>>> Would rpm be internal to the macports port command and leverage  
>>> rpm dependency checking or something?
>>
>> I think you're asking the wrong question.  The right question is  
>> not "is package format foo better than package format bar?" but  
>> rather "what exactly are we trying to do?"
>
> Was it about package formats (.rpm and .deb), or about package  
> managers (rpm and dpkg) ?

Yes. :)  I was using "package format" much more in the sense of  
"choosing that particular religion", one which includes a number of  
pre-existing tools and even certain policies that it would be wise to  
adhere to if either .rpm or .deb were chosen as the target package  
file format.  However, I don't think that the future lies with either,  
as I suspect you also agree.

>> I think the MacPorts project has essentially paralyzed itself with  
>> respect to package formats, and the subsequent task of package  
>> production, by taking the position of "we'll just support all  
>> package formats!  badly!", thus essentially rendering all choices  
>> equally mediocre and unappetizing to anyone wishing to experiment  
>> with this side of MacPorts.  That's a shame, because I think it's a  
>> good example of some bit of code filling a much-needed vacuum,  
>> tricking future generations into walking down the wrong path and  
>> into a bad part of town. :-)
>
> Wasn't that why we went with the destroot archives last year, "just  
> to get it started" ?

Frankly, I was never all that sure why the archivemode stuff came  
along, so I suspect you're asking the wrong person.   I've never used  
an archive for anything explicitly myself, and I always rather assumed  
that they were being used as a quick and dirty way of satisfying  
dependencies behind the scenes, should you choose to grab a copy of  
somebody else's archives, but that's just an assumption.  The problem  
is more complex than mere archival in any case, since there is no  
provision for recording install-time actions in the archive or  
specifying other package metadata.  I would also hope that the notion  
of signed packages would be on the very first version of the wish  
list. :)

> I mistook it for an technical/engineering problem first, when it  
> really wasn't.
> It shouldn't matter much for the big picture whether txt+tar or xml 
> +xar is used.

Nope!  Most of the interesting parts of the problem lie in how you  
take that tarball, or whatever, and add just enough secret sauce to  
cover the resolution of package dependencies (on other packages,  
specific system settings / accounts, ...).
>
> This is what Fink does with dpkg, and what was tried (in "dp_light")  
> with rpm.
> There was even some talk about reviving xpkg (using xar) to do it  
> for MacPorts.

That would be cool.

> "port xpkg" should be operational to create the xar archive (with  
> xml metadata).
> I guess it's just waiting for someone to complete the xpkg(1)  
> implementation ?

Pretty much, yeah!   I think xar/xpkg would be a fine selection,  
myself, since it seems to do a pretty good job of embodying the  
"really no more than you need" approach, while remaining extensible.   
At this point, xpkg(1) itself and the relevant xpkg support in  
MacPorts are the biggest blockers.  Some success with the mpab project  
would also help start digging the tunnel from the other side of the  
mountain, so to speak, but that's not strictly necessary for progress.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090324/daee4dc9/attachment-0001.html>