upgrade/migration from a directory to a link broken
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dpkg (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: dpkg
Upgrade (or migration) from a directory to a link is resulting in an empty directory instead of a symlink.
I have the following files in my install tree :
====
debian/
debian/
debian/
....
====
I also have the following debian/foo.install dh_helper file:
=====
debian/
debian/
=====
I build and install the deb, all is good.
Now I decide to move /usr/lib/foo/bar1 to /usr/share/foo/bar1 and keep only a link in /usr/lib/foo (so that the application continues to work).
I change debian/foo.install to:
====
debian/
debian/
====
and I add debian/foo.links with:
====
usr/share/foo/bar1 usr/lib/foo/bar1
====
I build, look at the deb using dpkg -c foo*.deb, it looks fine (files and link).
Now I install that deb.
I get /usr/share/foo/bar1 correct but /usr/lib/foo/bar1 is an empty directory instead of the expected symlink that I can see in the deb.
/usr/lib/foo/bar2 is correct, as is everything else.
================
I've got that situation many times before (firefox, xulrunner, seamonkey, prism, kazehakase, ..), here is xulrunner-1.9
when I've moved the plugins dir from /usr/lib/
ix:~/bzr/
drwxr-xr-x root/root 0 2007-11-20 23:49 ./usr/lib/
-rw-r--r-- root/root 8748 2007-11-20 23:49 ./usr/lib/
-rw-r--r-- root/root 18376 2007-11-20 23:49 ./usr/lib/
lrwxrwxrwx root/root 0 2007-11-20 23:49 ./usr/lib/
ix:~/bzr/
(Reading database ... 38489 files and directories currently installed.)
Preparing to replace xulrunner-1.9 1.9~b1+
Unpacking replacement xulrunner-1.9 ...
Setting up xulrunner-1.9 (1.9~b1+
ix:~/bzr/
total 32
-rw-r--r-- 1 root root 18376 Nov 20 23:49 libnullplugin.so
-rw-r--r-- 1 root root 8748 Nov 20 23:49 libunixprintplu
ix:~/bzr/
total 0
ix:~/bzr/
drwxr-xr-x 2 root root 4096 Nov 20 23:54 plugins/
To solve that, I have to either remove the package 1st or remove the empty dir afterwards and force a re-install.
This is (I am reliably informed) intentional behaviour in order to avoid potentially- confusing semantics. Multiple packages can own a given directory (and frequently do, e.g. /usr), and this is to prevent confusion when only one of them decides to turn it into a symlink. (Consider that one of the other packages that owns the directory might be installed later.) There are conceivably ways to work around this, but dpkg has chosen not to attempt it for simplicity and in order to force maintainers to consider this.
The standard workaround is to include a preinst that, on upgrade to the version in which you make this change, 'rm -rf's the directory; the link will then be created on unpack. Alternatively, if there might be non-dpkg-managed files in that directory, you should move it aside to a safe place in the preinst, and then move those files into the target of the symlink in the postinst.