upgrade/migration from a directory to a link broken

Bug #164228 reported by Fabien Tassin
2
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/tmp/usr/lib/foo/bar1/file1
debian/tmp/usr/lib/foo/bar1/file2

debian/tmp/usr/lib/foo/bar2/file3
....
====

I also have the following debian/foo.install dh_helper file:

=====
debian/tmp/usr/lib/foo/bar1
debian/tmp/usr/lib/foo/bar2
=====

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/tmp/usr/lib/foo/bar1 usr/share/foo
debian/tmp/usr/lib/foo/bar2
====

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/xulrunner-1.9b1/plugins to /usr/lib/xulrunner-addons/plugins:

ix:~/bzr/build-area$ dpkg -c ./xulrunner-1.9_1.9~b1+nobinonly-0ubuntu1_i386.deb | grep plugin
drwxr-xr-x root/root 0 2007-11-20 23:49 ./usr/lib/xulrunner-addons/plugins/
-rw-r--r-- root/root 8748 2007-11-20 23:49 ./usr/lib/xulrunner-addons/plugins/libunixprintplugin.so
-rw-r--r-- root/root 18376 2007-11-20 23:49 ./usr/lib/xulrunner-addons/plugins/libnullplugin.so
lrwxrwxrwx root/root 0 2007-11-20 23:49 ./usr/lib/xulrunner-1.9b1/plugins -> ../xulrunner-addons/plugins

ix:~/bzr/build-area$ sudo dpkg -i ./xulrunner-1.9_1.9~b1+nobinonly-0ubuntu1_i386.deb
(Reading database ... 38489 files and directories currently installed.)
Preparing to replace xulrunner-1.9 1.9~b1+nobinonly-0ubuntu1 (using xulrunner-1.9_1.9~b1+nobinonly-0ubuntu1_i386.deb) ...
Unpacking replacement xulrunner-1.9 ...
Setting up xulrunner-1.9 (1.9~b1+nobinonly-0ubuntu1) ...

ix:~/bzr/build-area$ ls -l /usr/lib/xulrunner-addons/plugins/
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 libunixprintplugin.so

ix:~/bzr/build-area$ ls -l /usr/lib/xulrunner-1.9b1/plugins
total 0

ix:~/bzr/build-area$ ls -ld /usr/lib/xulrunner-1.9b1/plugins
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.

Revision history for this message
Colin Watson (cjwatson) wrote :

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.

Revision history for this message
Colin Watson (cjwatson) wrote :

Marking Won't Fix per my previous comment on this bug.

Changed in dpkg:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.