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 -