Bug#626203: dpkg: handle better package upgrade replacing symlink by a folder
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 Holmgrenholmg...@debian.org Debian Developer signature.asc Description: This is a digitally signed message part.
Bug#626203: dpkg: handle better package upgrade replacing symlink by a folder
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) -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#626203: dpkg: handle better package upgrade replacing symlink by a folder
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 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#626203: dpkg: handle better package upgrade replacing symlink by a folder
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-1GNU 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-utils5.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
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
