apt/synaptic and multi-arch [LWN.net]

apt/synaptic and multi-arch

Posted Mar 15, 2005 21:35 UTC (Tue) by djao (subscriber, #4263)
In reply to: Try Ubuntu Hoary instead by proski
Parent article: Announcing Fedora Core 4 test1

Have you actually tried it on x86_64 with some i386 packages installed? Synaptic doesn't like when several packages with the same name are installed.

What you say is true, but Debian/Ubuntu don't help either, since they don't support any sort of mixed-arch x86-64 and i386 environment at all.

(Log in to post comments)

apt/synaptic and multi-arch

Posted Mar 15, 2005 21:38 UTC (Tue) by shahms (subscriber, #8877) [Link]

And the horrible, horrible chroot kludge used by Debian/Ubuntu doesn't count. It's so fugly, I can't believe they went that route. Then again, I'll bet it was devised by the same person who developed the ridiculous network config file format.

I'm not sure if the fault ultimately lies in apt or dpkg, but Synaptic on Fedora doesn't support multilib because apt doesn't.

apt/synaptic and multi-arch

Posted Mar 16, 2005 2:37 UTC (Wed) by Shewmaker (subscriber, #1126) [Link]

There are aspects of the RedHat approach that are ugly.

On Fedora Core 2 and RHEL4, there are i386 and x86_64 packages that claim to own the same binaries. As I understand it, rpm always overwrites the i386 binary with the x86_64 binary, but unfortunately this means that running "rpm -Va" on an "everything" install will show a large number of packages with md5sum differences.

I understand that defining rpm's behavior the way they have made creating their multiarch distro require less effort, but I do think it is ugly and it reduces the usefulness of rpm's verification capability. It would help if it reported the arch of the package in addition to the package name, but it seems wrong for a correctly installed system to look broken when you run "rpm -Va".

I also looked at a SuSE 9.2 system, and although not everything was installed, there were only a couple of multiarch packages that conflicted and those looked like unwanted mistakes in packaging and not a side affect of their methodology.

Perhaps in addition to defining the behavior of conflicting multiarch rpms to overwrite i386 with x86_64, rpm could also remove the conflicting files from the i386 package's file ownership list. The other clean alternative I can think of would be to make certain all i386 packages on a multiarch distro have lib subpackages so there are no file conflicts. I imagine that was the work RedHat is trying to avoid.

I kind of like the idea of having all 32-bit binaries in a separate filesystem hierarchy than the 64-bit binaries. Chroot may not be the ideal way to accomplish this, but perhaps environment modules would be.