[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: redhat abe

On Fri, 28 Jan 2005, Axel Thimm wrote:
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

I wouldn't say "easily", but it does fit into apt's design.

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

..and so does smartpm, dunno about red-carpet and all the gazillion other depsolvers out there.

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?

Ugh, no thanks. Feel free to patch your version of apt with it, but from my POV it's just too ugly to live with.

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

...and even I'm not really from "multilib world" since I don't have x86_64 boxes at home. My next system is going to be that but whether it happens this year, next year or the one after that I dunno :)

- Panu -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]