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 -
