Universal and binary builds

[Anders F Björklund]

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

If it's just about the file format, then yes one might as well  
use .tar or .xar instead.

> 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" ?

I don't think it was the archive format that was the big obstacle to  
MacPorts binaries...

> "What's ``the right path'' then?", I hear you ask.  Glad you  
> asked!   The right idea is to go back to that more fundamental  
> "what exactly are we trying to do?" question and try to answer it  
> first, deciding what constitutes a package in MacPorts-land and how  
> much of a role, if any, the MacPorts project wants to take in  
> producing packages for popular consumption.  Once you have those  
> answers, assuming that you've decided to go anywhere with packaging  
> at all, you can attack the problem by writing something strictly to  
> spec, swearing under pain of death that it will absolutely never be  
> any more complicated or feature-full than it needs to be at any  
> given time.   That will keep you out of the La Brea Tarpit of  
> package management tools, where the temptation to be too clever/ 
> forward-looking can quickly lead to an explosion of options and  
> special-case behavior that rapidly complicates what should actually  
> be relatively simple.

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.

I found it easier to build my packages outside of MacPorts (whether  
application
bundles or RPM packages), while the project tries to answer the basic  
question...

> [...] It would be nice[er] IMO if a solution could be devised which  
> makes "port install foo" and "pkg install file:///foo.xar" lead to  
> exactly the same place.  Well, to be even more precise, it would be  
> nicer still if "port install foo" simply became a wrapper around  
> "port package foo -o /var/tmp/<somewhere>/foo.pkg && pkg install  
> file:///var/tmp/<somewhere>/foo.pkg && rm -f /var/tmp/<somewhere>/ 
> foo.pkg" so that the base MacPorts infrastructure could just get  
> out of the business of directly installing bits on the system.

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.

"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 ?

--anders