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 -