Some background: I'm migrating my home server to new hardware and considering
changing the OS to 64-bit as well. Since apt now supports multiarch, I thought
I'd do this by installing a 64-bit kernel first and then updating userspace bit
by bit as necessary and as time permits. Unfortunately, reality turned out to
be much more complicated.
If a package with Architecture: all depends on a package with a specific
architecture, then that dependency can't be fulfilled by a foreign package. In
my scenario above, this caused apt to think half the system was broken as soon
as dpkg and apt themselves had been changed to amd64 versions. For example:
xbase-clients : Depends: x11-apps but it is not installed
Depends: x11-session-utils but it is not installed
Depends: x11-xkb-utils but it is not installed
Depends: x11-xserver-utils but it is not installed
Depends: xauth but it is not installed
Depends: xinit but it is not installed
However, dpkg -l shows this:
ii x11-apps 7.7~2 i386 X applications
ii x11-session-utils 7.6+2 i386 X session utilities
ii x11-xkb-utils 7.7~1 i386 X11 XKB utilities
ii x11-xserver-utils 7.7~3 i386 X server utilities
ii xauth 1:1.0.7-1 i386 X authentication utility
ii xinit 1.3.2-1 i386 X server initialisation tool
Clearly those packages are installed and apt's complaints are baseless.
This seems to affect dpkg as well.
Hello Cross-grading an entire system is not a documented or supported procedure. You could possibly still proceed as you intended, if you are adventurous. It will take some encouraging of dpkg (lots of ‘--force-FOO’) and you will not receive support for the procedure here. Probably simpler to install a fresh amd64 system. This is by design. At a later stage of the multi-arch transition it may be changed, but not now. <https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages> As above, this is by design. The developers are aware of the highlighted dependency handling and the desire to perhaps move away from it eventually. I am therefore prone to closing this as not-a-bug, the difficultly in cross-grading a system is neither apts or dpkgs fault, they handle the situation correctly. Regards
I am aware of the unsupported nature of this operation. It used to be even harder, but multiarch makes it reasonably easy since programs are much less likely to break due to mismatched libraries. Half the reason I'm doing this is to explore the limits of what's possible, and because it's an interesting technical challenge. The other half of the reason is that I'm too lazy to dig up all the customizations I've done over the seven years since this system was installed and migrate them to the new system. However, I might be grossly overestimating the amount of effort required, and a fresh install would probably also result in a somewhat cleaner /etc. Perhaps it could be implemented as a configuration option to begin with, and change the default later? ... Several hours of furious coding and testing later: I managed to put together a Python script which changes the architecture of an installed Debian system from i386 to amd64. I didn't even need to use any --force; processing packages in correct order by dependencies is enough, since dpkg does less dependency checks than apt. It's not perfect, but it left me with only about two dozen broken packages to be fixed by hand, as opposed to the several hundreds I encountered when trying to do this manually.
Hi! Well, dpkg *does* have native support for cross-grading, see the last section in the announcement mail [0], apt does not though. That does not mean the current package metadata will allow this in all cases. I guess that wiki page might be outdated in other places too, for example cross-multiarch compilation is supported too, but I've not checked the page in detail. [0] <https://lists.debian.org/debian-devel-announce/2012/03/msg00005.html> If dpkg fails on some packages, one issue might be because they are not yet properly marked with a Multi-Arch field, as noted also in the announcement mail. Thanks, Guillem
A small clarification, while the above is true, marking them with Multi-Arch fields might not be a correct solution, because losening some dependencies might allow producing broken dependency chains, in cases like interpreters and loadable modules for example. So it's true that Arch:all packages might hinder cross-grading, but that's independent from the tools supporting performing the actual action, as I mentioned before. Thanks, Guillem
My script does handle the Multi-Arch field and its absence. Almost all of the issues were multiarch-enabled packages that depended on a pre-multiarch package. Installing the new arch version of the dependency left the old arch version of the dependant broken. I added a section at the end of the script to clean up such broken packages. As of now, there's only two real problems in the cross-grading process: libclutter-gst-1.0-0 has a binNMU with different changelogs, and can't coexist with itself even though it is Multi-Arch: same. postgresql won't restart after cross-grading since its binary data format is arch-dependant. Would this script be of interest to the Debian community? If so, I can share it.
http://blog.zugschlus.de/archives/972-How-to-amd64-an-i386-Debian-installation-with-multiarch.html describes a procedure that gets away without --force, but needs a lot of "Yes, I understand this will break my system" and has yet only been proven for a very basic system. Greetings Marc
http://blog.zugschlus.de/archives/972-How-to-amd64-an-i386-Debian-installation-with-multiarch.html describes a procedure that gets away without --force, but needs a lot of "Yes, I understand this will break my system" and has yet only been proven for a very basic system. Greetings Marc