Re: dpkg: multiarch symlink not present in fresh installs
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
Reply to: