/var/lib/dpkg/info/$arch still a directory on new installs

[Steve Langasek]

Binary package hint: dpkg

debootstrap unpacks base packages in alphabetical order:

I: Unpacking required packages...
I: Unpacking adduser...
I: Unpacking base-files...
I: Unpacking base-passwd...
I: Unpacking bash...
I: Unpacking bsdutils...
I: Unpacking busybox-initramfs...
I: Unpacking coreutils...
I: Unpacking cpio...
I: Unpacking dash...
I: Unpacking debconf...
I: Unpacking debconf-i18n...
I: Unpacking debianutils...
I: Unpacking diffutils...
I: Unpacking dpkg...

So before the dpkg preinst script has ever been run, a number of other packages have been unpacked - autocreating /var/lib/dpkg/info/$arch as a directory in the process. So any new installs with this version of dpkg are going to have a directory instead of a symlink.

This may be related to some of the problems still being reported for alpha 3 on the preinstalled images.

[Colin Watson (cjwatson)]

However, debootstrap 1.0.28ubuntu1 now creates the symlink before any of that. Anything that's debootstrapping natty needs to make sure to use at least this version.

The reason I don't like approaches such as 'mv /var/lib/dpkg/info/armel/* /var/lib/dpkg/info/ && rmdir /var/lib/dpkg/info/armel && ln -sf . /var/lib/dpkg/info/armel' (as you suggested on IRC) are that they're unsafe; a power failure in the middle of that will result in a corrupted dpkg database.

[Martin Pitt (pitti)]

Does not break the alpha-3 images/installation, and it seems the recent debootstrap change took care of most of this. Moving milestone.

[Steve Langasek (vorlon)]

On Wed, Mar 02, 2011 at 09:43:50AM -0000, Colin Watson wrote:
> However, debootstrap 1.0.28ubuntu1 now creates the symlink before any of
> that. Anything that's debootstrapping natty needs to make sure to use
> at least this version.

Aha, ok.

> The reason I don't like approaches such as 'mv
> /var/lib/dpkg/info/armel/* /var/lib/dpkg/info/ && rmdir
> /var/lib/dpkg/info/armel && ln -sf . /var/lib/dpkg/info/armel' (as you
> suggested on IRC) are that they're unsafe; a power failure in the middle
> of that will result in a corrupted dpkg database.

Yes, I don't like it either, I was only suggesting it in the context of a
quick test. If we needed to do this for a real upgrade fix, I would
suggest:

  if [ -d /var/lib/dpkg/info/$arch ] && ! [ -L /var/lib/dpkg/info/$arch ]; then
    cp -a /var/lib/dpkg/info/$arch/* /var/lib/dpkg/info
  fi
  if ! [ -L /var/lib/dpkg/info/$arch ]; then
    if [ -d /var/lib/dpkg/info/$arch ]; then
      mv /var/lib/dpkg/info/$arch /var/lib/dpkg/info/${arch}.dpkg-bak
    fi
    ln -sf . /var/lib/dpkg/info/$arch
  fi
  rm -rf /var/lib/dpkg/info/${arch}.dpkg-bak

That's not 100% safe either wrt database corruption, but it reduces the
window to the time between the directory move and the symlink creation, and
should be recoverable by hand at every point.

But I think we don't want to do this until the dpkg multiarch db layout is
finalized, anyway.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Launchpad Janitor (janitor)]

This bug was fixed in the package dpkg - 1.16.0~ubuntu4

---------------
dpkg (1.16.0~ubuntu4) natty; urgency=low

  * Merge from git://git.debian.org/users/hertzog/dpkg.git
    pu/multiarch/snapshot/20110314 for updated multiarch support. This
    reverts the dpkg database changes from the earlier merge in favor of a
    single-directory dpkg db again.
    - Fix typo in «dpkg-name --overwrite» argument parsing so that it
      actually works at all. Thanks to Ivan Gagis <email address hidden>.
      LP: #728708
  * Update the version checks for the multiarch db format to point to
    1.16.0~ubuntu4 instead of the (not-yet-released) 1.16.0.
  * On upgrade from 1.16.0~ubuntu[1-3], if /var/lib/dpkg/info/$arch is a
    directory, migrate the contents to var/lib/dpkg/info; and handle the
    reverse on downgrade. This does not handle metadata for packages of
    foreign architectures; if this affects you, come talk to me. :-)
    LP: #727603.
  * add new variables, DEB_HOST_MULTIARCH and DEB_BUILD_MULTIARCH, that
    return the "ideal" GNU triplet for each architecture which should be
    used as the path component for library installation.
 -- Steve Langasek <email address hidden> Mon, 14 Mar 2011 18:12:06 -0700