Hi! On Tue, 2011-03-01 at 14:41:47 +0000, Colin Watson wrote: > On Tue, Mar 01, 2011 at 02:36:24PM +0100, Raphael Hertzog wrote: > > On Tue, 01 Mar 2011, Colin Watson wrote: > > > I noticed this > > > (https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/727106) while doing > > > a debootstrap test of natty. I think we need to be consistent about the > > > compatibility symlink being present, since it's a pain to migrate this > > > from a directory to a symlink, and since I expect there to be software > > > kicking around for a while that relies on it. > > > > I deliberately added it only on upgrade. I understand you want to keep it > > that way for natty but very few software should look up files directly in > > /var/lib/dpkg/info/ and those that do should be converted to use > > dpkg-query --control-path. > > > > $ dpkg-query --control-path dpkg-dev md5sums > > /var/lib/dpkg/info/i386/dpkg-dev.md5sums > > > > I think it's perfectly legitimate to have the few offenders fixed in time > > for wheezy. > > Hmm. I'm honestly concerned about the inconsistency here; it will > introduce bugs that depend on how the user got there (install squeeze > and upgrade, vs. install wheezy directly), which in my experience we try > very hard to avoid. > > > BTW, what's difficult to move from a directory to a symlink? > > > > $ cd /var/lib/dpkg/info > > $ mv <arch>/* ./ > > $ rmdir <arch> > > $ ln -sf . <arch> > > A power failure during that process will leave a corrupted dpkg > database.
As I mentioned on the IRC channel, and to Steve in particular when he mentioned the Ubuntu dpkg upload, the current db layout is defintely not the final one. It has several problems, mainly of fragility as you point out. The dpkg db (status, info control files, etc) should *never* get into a state from where it cannot be recovered, at least from "normal" operations. With the current multiarch db layout crossgrading dpkg (something that is currently supported, although with a --force option) will completely break dpkg. Currently installed foreign packages will also break dpkg. Fixing this implies unneeded db layout migration for most of the packages. The new db layout I've been working on, uses «<admindir>/pkg.file» for all packages except multiarch_same which use «<admindir>/pkg:arch.file» (falling back to «<admindir>/pkg.file» if the former is not present), which are the only ones needing to be distinguished among them. It does not really matter if we have a foreign package installed, as we can only have one at any point in time. The multiarch_same packages will get their db layout transparently upgraded when any of it's instaces gets installed. I've also added checks checks and two-staged safe db layout downgrade support on dpkg downgrade. I hope to have something pushable probably today. The dpkg crossgrade scenario also has implications for the pkg names when interfacing with dpkg (either input or output). For example, if we assume pkg for native and pkg:arch for foreign packages, then on crossgrade the world view of apt and dpkg will not match at some point in the upgrade. So it's never safe to assume libsame == libsame:native. I'll come back to this on the previous thread about multiarch package names, later today. thanks, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
