Universal and binary builds

[Anders F Björklund]

Jordan K. Hubbard wrote:

>>> 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 meant it as in if talking about archives (for port) or packages  
(for rpm).

If it's "just an archive format", then port doesn't need more than  
rpm2cpio
(or similar) to pry the bits open and then extract the destroot  
contents...
But if choosing the particular religion and building "real" packages  
for it,
then it probably would need to follow a bunch of rules and traditions  
yes.

RPM still works, but I don't think the "dp_light" alternative is in  
MP future.

>>> 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 do enable archivemode though, since it's a good way to save time  
and space
for me. Not having to rebuild from source, and being able to compress  
inactive.

I've found the darwinports/macports archives (.tgz) to work "just as  
well" as
the FreeBSD packages. Then again, that's "not very good" beyond  
initial install.

> I would also hope that the notion of signed packages would be on  
> the very first version of the wish list. :)

There's .tgz.asc (for GPG) which seems to be "good enough" in the  
same way...
Not sure if xar offers much extra help in the signature department,  
though ?

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

The current "solution" is to just dump the Portfile's Tcl for reading  
"later".
Then again, port also reads the registry rather than look at the  
archive data.

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

Cool, but not very popular ? Then again, the release xar 1.6 is  
slightly delayed.
(it's been in the "development" stage since 2007, the svn is still  
being updated)

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

There's a "xpkg-0.2dev" lurking, if anyone else wants to continue  
developing it...
See http://web.archive.org/web/20061230221957/http://www.xpkg.org/  
for 0.1.3

--anders