hi

summary of bug 406689:

mozilla-imagezoom installs those files and dirs:

$ dpkg-deb -c mozilla-imagezoom_0.2.7-7_all.deb | grep usr/lib/iceape
drwxr-xr-x root/root         0 2006-12-28 05:55 ./usr/lib/iceape/
drwxr-xr-x root/root         0 2006-12-28 05:55 ./usr/lib/iceape/defaults/
drwxr-xr-x root/root         0 2006-12-28 05:55 ./usr/lib/iceape/defaults/pref/
lrwxrwxrwx root/root         0 2006-12-28 05:55 ./usr/lib/iceape/defaults/pref/imagezoom-defaults.js -> /etc/mozilla-extensions/imagezoom.js

then iceape-browser would like to install this symlink
# dpkg-deb -c /d/archives/iceape-browser_1.0.7-2_i386.deb | grep usr/lib/iceape/defa
lrwxrwxrwx root/root         0 2007-01-04 21:17 ./usr/lib/iceape/defaults -> ../../share/iceape/defaults

The two requests are incompatible. The choice of dpkg is to silently
ignore the iceape symlink. As a result, iceape is unusable.

I think that dpkg should not silently ignore the symlink.  I think
that dpkg should stop installing iceape-browser and return an error.

thanks for your attention

a.

Hi,

the same problem happens, when a directory is replaced by a symlink
during the upgrade of a package. I am attaching 2 versions of the
testpackage tp to illustrate the problem. Version 1 ships the file
/usr/lib/tp/tp.cfg and the directory /usr/lib/tp/log. Version 2 moves
tp.cfg to /etc and the directory to /var/log/tp and ships appropriate
symlinks in /usr/lib/tp/. After the installation of version 1 we have:

$ ls -l /usr/lib/tp
insgesamt 4
drwxr-xr-x 2 twerner twerner 4096 12. Okt 15:51 log
-rw-r--r-- 1 twerner twerner    0 12. Okt 15:51 tp.cfg

After the upgrade to version 2 we have:

$ ls -l /usr/lib/tp
insgesamt 4
drwxr-xr-x 2 twerner twerner 4096 12. Okt 15:51 log
lrwxrwxrwx 1 twerner twerner   11 12. Okt 16:00 tp.cfg -> /etc/tp.cfg

After the installation of version 2 on a fresh system we have the
correct symlink:

$ ls -l /usr/lib/tp
insgesamt 0
lrwxrwxrwx 1 twerner twerner 11 12. Okt 16:00 log -> /var/log/tp
lrwxrwxrwx 1 twerner twerner 11 12. Okt 16:00 tp.cfg -> /etc/tp.cfg

The maintainer of tp can handle that problem via preinst but it is
difficult to spot because dpkg does not fail during the upgrade (no
warning either). Because I have seen RC bugs because of this (#468954) I
will increase the severity of this bug to important. IMHO dpkg should
fail is such cases with a useful error message.


Cheers,
Torsten

No, he can't.  At least not in a sane way, i.e. without removing all
files under /usr/lib/tp and breaking the rollback that usually happens
if unpacking the new version of the package fails.  This has to be done
in the postinst, when there should be no files left in the directory.

Only the inverse conversion (symlink -> directory) can be done (has to
be done, actually) in preinst scripts.

And how are you going to turn a directory into a symlink, then?  Also,
there are certainly systems where the local administrator has turned a
standard directory, say /usr/share, into a symlink for one reason or the
other.  Certainly such setups should not suddenly break, should they?

I guess this bug is "wontfix"; however, the procedures how to convert a
directory into a symlink and vice versa should be better documented, as
I couldn't find anything about this topic in the Policy Manual,
Developer Reference or New Maintainer Guide.

Cheers,
       Sven

Okay, but then it is not 'wontfix'.

Cheers,
Torsten

severity 406715 normal
retitle 406715 dpkg should warn the user when there's a dir/symlink mismatch between the package and the system
thanks

And it's not important. This is one of those "it's not a bug but a
feature". Dpkg could emit a warning to show that it did that deliberately
and this is what this bug is about.

Cheers,

I'd disagree on the severity of this bug.

Tried to create a package with a compatibility symlinks on legacy
pathnames. That proved to be a poor idea, since now I'm getting empty
directories on legacy pathnames instead of symlinks when upgrading the
packages.

No even a warning about this and I would've expected the install process
to halt right there.

The preinst solution could work with moving the old directories
elsewhere and remove them on postinst after a successful installation
(to support rolling back to earlier version).

But is this something we want to do in all packages that have this problem?

Regards,

   Jussi

Just to clarify, when I have a package a which contains a directory b
and I release a new version from it in which I've replaced directory b
with a symlink, the user who upgrades package a from old version doesn't
get a symlink b but an empty directory b.

Assuming the directory b contained a lot of files and subdirectories,
any software that is unaware of the directory hierarchy changes in
package a tries to search stuff from the empty directory b and will
horribly break.

In these cases, upgrading via removing and reinstalling package a will
give a desired result (symlink b instead of empty directory b).

In my opinion, dpkg should *at least* warn about this.

Regards,

   Jussi