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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
