Hi,

I'll be uploading dpkg 1.16.2 targeting unstable, by the end of
this weekend or beginning of next week the latest (after some final
polishing). Some pretty important points follow, the first section
in particular.


On-disk db damage
-----------------

The previous multiarch in-core db layout was bogus, resulting in a
possible inconsistent or broken on-disk db. If you are running any
dpkg derived from code that has never been in the main git repo (this
includes dpkg from the jenkins test builds [T], dpkg from experimental,
dpkg from Ubuntu, one of the personal pu/ branches, etc), any of the
following might affect you.

[T] http://jenkins.grml.org/job/dpkg-test-source/

With those dpkg versions, when installing a M-A:same instance of
package P arch A, when a previous non-M-A:same version of package P
arch B was present in a config-files state, the installation would
incorrectly remove the control files on the infodb for the arch B
instance. You should check for any packages in the status db w/o
matching files under /var/lib/dpkg/info/.

Another effect of the bogus in-core db layout affected the disappearing
logic, so if you have been running any such dpkg versions, you should
also check in the logs that no package has been improperly disappeared,
although the installed files should still be present.

And finally (well, these are just some of the effects I've explicitly
looked for after revealing them through code review, there could be more
related to this, but I've not bothered after having reworked the in-core
db layout), upgrading from those versions to the new dpkg 1.16.2 might
cause the status db to get messsed up in some conditions. Before
upgrading, you should either downgrade to a non-multiarch enabled dpkg, or
make sure there's no package present (i.e. with status >= config-files)
with a mix of M-A:same and non-M-A:same instances. If there's such package
with two instances, the new dpkg will consider that a “cross-grade” and
as such replace one of them with the other, depending on the order they
are parsed, but leaving any control files untouched; if there's more than
two instances the new dpkg will outright refuse to parse such bogus and
inconsistent status db.

Do not file any bug report if you upgraded from a system with a damaged
db, w/o first reproducing it on a clean system.

This is NOT related to Aptosid/Debian Sid users

Yeah, (simplification of) crossgrades is one of the plus-points. You can do this without multiarch already, but its a bit hard. Guillem lined out how to do it if you have dpkg with multiarch support installed (and an archive in which the needed packages are correctly multiarchified). The support to deal with this situation is implemented in APT, thats not the problem, what Guillem means is that you currently have to download the dependency of dpkg with APT and install them with dpkg directly. So what he means with APT missing cross-grade support is that you can't cross-grade an essential package like dpkg with APT (like: apt-get install dpkg:amd64) as APT will remove dpkg:i386 and then install dpkg:amd64 which obviously doesn't work as there is no dpkg anymore installed to install the new dpkg… (that dpkg can override itself [and other packages] is a new feature which we just do not support yet. As the theory behind is properly complicated and isn't defined yet [just implemented - maybe, i haven't seen public code yet] and we can live without it in 99% of all cases this will not be implemented soon: Crossgrades are easy to fuck up for a user, it doesn't really help if APT makes that easy if it just leads to more users fucking it up [as where is more to it than just installing a few packages - and that the only thing APT could do]).

Note to readers: If you have more questions marks over your head now after reading this than before reading it: Forget it. Multi-Arch implementation and the ideas and problems behind it are crazy shit. At the time debian wheezy will freeze (~3 months) we are hopefully at a point there i can say what an end-user and/or a developer can do with it without writing stuff like the above which isn't easy to understand. And - god is my witness - i tried hard to keep it easy, it could be a lot worser…


If you want to think about features of Multi-Arch, don't think about cross-grades. Aim lower for now: e.g. hassle-free (in terms of installation) skype, flash, $nonfree-app on amd64. wine for amd64 with out-of-the-box opengl correctly working. Developers can aim for simpler cross-building (even through that is stage2)…

Will debian devs add multi-arch support for apt itself to handle the situation where the package with the old arch is removed first and then install the new arch with something more streamlined? That's the big missing piece right there