Re: apt-rpm & 64-bit Fedora Core 4
Panu Matilainen <[email protected]> Thu, 24 Nov 2005 04:34:03 -0800 (PST)
| Newsgroups | gmane.linux.conectiva.apt-rpm |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 24 Nov 2005, Axel Thimm wrote: > On Thu, Nov 24, 2005 at 08:46:19AM +0200, Panu Matilainen wrote: >> This isn't real multilib support for apt by any means, but it'll allow >> using apt-rpm in presence of multilib packages. It works by renaming >> multilib packages internally so that all packages listed in >> RPM::Allow-MultiArch:: become >> pkgname -> pkgname.x86_64 >> pkgname -> pkgname.i386 >> ..and "pkgname" provide is added to the renamed variants. It's pretty much >> like how Allow-Duplicated works. To make user experience a bit nicer >> you'll probably want a little help from Lua, attached as well. > > That's nice. Where's the catch? Only that package names are presented > differently? The devil's in the details. As apt's depsolver is blissfully ignorant about this change and how it should behave in presenece of multilib, it misses out on things like package obsoletes, IIRC direct dependencies on package names are a bit problematic too.. and complex upgrades are even more complex, for the same reason. Oh, and it's quite brittle because of the above and the fact that you need to manually maintain the list of multilib packages. >> Attached is the patch + example configuration for RHEL 3'ish system + Lua >> helper script. For FC you'll need to add a pile of more stuff into >> multilib.conf I think. > > Why not use a wildcard on this? Well you can use regexps in RPM::Allow-Multiarch:: but they are of limited value since a) you can't match against the architecture there b) you want to avoid the renaming at all costs because of the dependency issues mentioned above. For example you don't want to put "festival" in there just because it's i386 on x86_64, only the packages where both 32bit and 64bit versions exist. Oh, I've looked into doing this renaming dynamically but every version I came up with was so wildly unstable I gave up... it'd require pretty significant changes to how apt stores and handles things internally to *really* support this and ... well, since smartpm and yum already know how to deal with this, I don't consider it worth the effort anymore. - Panu -