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
Attachment:
pgptj9GjWXUWP.pgp
Description: PGP signature
