On Fri, Jan 28, 2005 at 11:58:00AM +0200, Panu Matilainen wrote:
On Thu, 27 Jan 2005, Ralf Corsepius wrote:
>I know apt's code is ... ... leaves a lot to be desired, but it doesn't
>require that much effort to maintain the package.
Maintaining the package ain't hard, but developing apt-rpm into
various directions required by FC (multilib, new repodata format) is
just about as fun as pulling teeth without anesthesia.
The fun depends on whether you are the patient or the doctor ;)
The new repodata is something that would be sanely implementable
into apt,
I think that's the least that needs to be done. As you say it is
easily fixable, and also until then it can be taken care of
server-side (where the question arises, what does the new repodata
format really buy us other than being xml? I was under the impression
that all depsolvers, rpm and deb and its cat were going to use it,
turns out it's yum and up2date only).
multilib as used in FC and RHEL (namely packages with same nevr but
different arch simultaenously installed) is something that doesn't
fit nicely into it's design. And that's putting it somewhat
mildly. I've actually tried various approaches to adding multilib
support to apt with varying success, however none of work well
enough to be actually usable.
There is a simple patch by the CERN folks used for ia64 by spliting
apt's processing of i386 and ia64 into different package worlds (in
apt-rpm's archives). Can that be used as for an initial multilib
approach?
apt's lack of multilib is a PITA, but you must also consider that
apt's development community has only one member coming from the
multilib world, the masochist sharing Panu's mail address ... ;)
--
Axel.Thimm at
ATrpms.net