redhat abe

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050128/a7357efe/attachment.sig>