Debian Bug report logs - #626203
dpkg: handle better package upgrade replacing symlink by a folder

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dpkg: handle better package upgrade replacing symlink by a folder

Date: Mon, 09 May 2011 21:57:41 +0200

Package: dpkg
Version: 1.16.0.3
Severity: wishlist

Hey,

as said on irc, it'd be nice if dpkg could handle package upgrade
involving symlinks and directories a bit more nicely.

In this case, libexo-common upgrade replaced two symlinks by
directories, and without any special care, the error is not really
clear.

Debdiff between two packages were:

Differences in libexo-common between 0.6.0-3 and 0.6.1-1
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-------------------------------------
-rw-r--r--  root/root
/usr/share/doc/exo/html/el/images/exo-preferred-applications-internet.png
-rw-r--r--  root/root
/usr/share/doc/exo/html/el/images/exo-preferred-applications-utilities.png
-rw-r--r--  root/root
/usr/share/doc/exo/html/el/images/exo-preferred-applications-webbrowser-custom.png
-rw-r--r--  root/root
/usr/share/doc/exo/html/el/images/exo-preferred-applications-webbrowser-menu.png
-rw-r--r--  root/root
/usr/share/doc/exo/html/sv/images/exo-preferred-applications-internet.png
-rw-r--r--  root/root
/usr/share/doc/exo/html/sv/images/exo-preferred-applications-utilities.png
-rw-r--r--  root/root
/usr/share/doc/exo/html/sv/images/exo-preferred-applications-webbrowser-custom.png
-rw-r--r--  root/root
/usr/share/doc/exo/html/sv/images/exo-preferred-applications-webbrowser-menu.png

Files in first .deb but not in second
-------------------------------------
lrwxrwxrwx  root/root   /usr/share/doc/exo/html/el/images -> ../C/images
lrwxrwxrwx  root/root   /usr/share/doc/exo/html/sv/images -> ../C/images

Control files: lines which differ (wdiff format)
------------------------------------------------
Installed-Size: [-1120-] {+1356+}
Version: [-0.6.0-3-] {+0.6.1-1+}

(without anything done in preinst)

And upgrade logs:

Unpacking replacement libexo-common ...
dpkg: error processing /home/corsac/debian/pkg-xfce/scripts/pbuilder/xfce/build-sid-amd64-trunk/./libexo-common_0.6.1-1_all.deb (--unpack):
 unable to open '/usr/share/doc/exo/html/C/images/exo-preferred-applications-internet.png.dpkg-new': No such file or directory
configured to not write apport reports
                                      Processing triggers for hicolor-icon-theme ...
Errors were encountered while processing:
 /home/corsac/debian/pkg-xfce/scripts/pbuilder/xfce/build-sid-amd64-trunk/./libexo-common_0.6.1-1_all.deb

Regards,
-- 
Yves-Alexis

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg depends on:
ii  coreutils               8.5-1            GNU core utilities
ii  libbz2-1.0              1.0.5-6          high-quality block-sorting file co
ii  libc6                   2.13-2           Embedded GNU C Library: Shared lib
ii  libselinux1             2.0.98-1+b1      SELinux runtime shared libraries
ii  xz-utils                5.0.0-2          XZ-format compression utilities
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt                           0.8.14.1   Advanced front-end for dpkg

-- no debconf information

Message #10 received at 626203@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Yves-Alexis Perez <corsac@debian.org>

Cc: 626203@bugs.debian.org

Subject: Re: dpkg: handle better package upgrade replacing symlink by a folder

Date: Mon, 9 May 2011 16:38:52 -0500

Hi,

Yves-Alexis Perez wrote:

> as said on irc, it'd be nice if dpkg could handle package upgrade
> involving symlinks and directories a bit more nicely.

See also [1], [2], and [3].

The intent of the current behavior is that the sysadmin is free to use
symlinks to cause files in one directory to appear on a different
partition, and dpkg will leave that alone rather than replacing it
with a directory.  For symmetry, dpkg will not automatically replace a
directory with a symlink, either.

Better semantics, implemented in maintainer scripts for many packages,
are:

 - after a directory changes to a symlink in the shipped package,
   change the directory on disk to a symlink, if it is a directory and
   is empty.  If it is not empty, make a backup and then put a symlink
   there.

 - before a symlink changes to a directory in the shipped package,
   check if there is a symlink to the shipped target there on disk.
   If so, remove the symlink and replace it with a directory.  (If
   not, leave the symlink alone.)

After a package has been unpacked, dpkg doesn't actually know which
files were originally directories or symlinks, so it can't currently
implement these semantics internally.  Maybe some mitigating features
would be possible, though?

 - teaching best practices about directory <--> symlink transitions to
   dpkg-maintscript-helper

 - adding a file to declare which directories changed to symlinks (and
   to where) or vice versa, and in which versions

[1] http://bugs.debian.org/316935
[2] http://bugs.debian.org/406715
[3] http://bugs.debian.org/182747

Message #15 received at 626203@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 626203@bugs.debian.org

Cc: Yves-Alexis Perez <corsac@debian.org>

Subject: Re: Bug#626203: dpkg: handle better package upgrade replacing symlink by a folder

Date: Tue, 10 May 2011 16:32:59 +0200

On Mon, 09 May 2011, Jonathan Nieder wrote:
> The intent of the current behavior is that the sysadmin is free to use
> symlinks to cause files in one directory to appear on a different
> partition, and dpkg will leave that alone rather than replacing it
> with a directory.  For symmetry, dpkg will not automatically replace a
> directory with a symlink, either.

The thing that we could do better is detect when we install two different
files in the same place and error out earlier rather than when we're
trying to remove the .dpkg-new twice.

That's why I told Corsac to go ahead and submit the bug.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)

Message #20 received at 626203@bugs.debian.org (full text, mbox, reply):

From: Magnus Holmgren <holmgren@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 626203@bugs.debian.org, "Yves-Alexis Perez" <corsac@debian.org>

Subject: Re: dpkg: handle better package upgrade replacing symlink by a folder

Date: Mon, 17 Sep 2012 12:16:23 +0200

[Message part 1 (text/plain, inline)]

On måndagen den 9 maj 2011, you stated the following:
> Hi,
> 
> Yves-Alexis Perez wrote:
> > as said on irc, it'd be nice if dpkg could handle package upgrade
> > involving symlinks and directories a bit more nicely.
> 
> See also [1], [2], and [3].
> 
> The intent of the current behavior is that the sysadmin is free to use
> symlinks to cause files in one directory to appear on a different
> partition, and dpkg will leave that alone rather than replacing it
> with a directory.  For symmetry, dpkg will not automatically replace a
> directory with a symlink, either.
> 
> Better semantics, implemented in maintainer scripts for many packages,
> are:
> 
>  - after a directory changes to a symlink in the shipped package,
>    change the directory on disk to a symlink, if it is a directory and
>    is empty.  If it is not empty, make a backup and then put a symlink
>    there.
>
> After a package has been unpacked, dpkg doesn't actually know which
> files were originally directories or symlinks, so it can't currently
> implement these semantics internally.

This symmetry argument doesn't strike me as very persuasive. The sysadmin may 
very well want to move a directory and put a symlink, pointing to the new 
location, in its place, but how often does one replace a symlink with a copy 
of the directory it points to? In the case that a package replaces a directory 
with a symlink, the package upgrade would normally leave us with an empty 
directory. I can't see how that could ever be considered the correct and 
desired result. Now, if there are unowned files or files from other packages 
in the directory it must of course not be removed - that's either something 
the sysadmin has to sort out, or an error.

One technical problem seems to be that files which were in the old version of 
a package but not in the new are not removed until after the files in the new 
package have been unpacked (and after the point of no return; policy 6.6, step 
5). dpkg will thus either have to determine ahead of that point what 
directories will disappear, or perform an extra step of replacing empty 
directories with symlinks. But in any case I don't think dpkg needs to know 
which files where previously directories but now should be symlinks.

>  - before a symlink changes to a directory in the shipped package,
>    check if there is a symlink to the shipped target there on disk.
>    If so, remove the symlink and replace it with a directory.  (If
>    not, leave the symlink alone.)

This opposite direction is clearly more complicated, but another sign that a 
symlink should be replaced with a separate directory is when otherwise files 
from different packages would overwrite each other.

-- 
Magnus Holmgren        holmgren@debian.org
Debian Developer 

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.