gcc-multilib (4:4.7.2-1, amd64) provides a symbolic link for
/usr/include/asm

# dpkg --contents /var/cache/apt/archives/gcc-multilib_4%3a4.7.2-1_amd64.deb
drwxr-xr-x root/root         0 2012-09-27 02:02 ./
drwxr-xr-x root/root         0 2012-09-27 02:02 ./usr/
drwxr-xr-x root/root         0 2012-09-27 02:02 ./usr/share/
drwxr-xr-x root/root         0 2012-09-27 02:02 ./usr/share/doc/
drwxr-xr-x root/root         0 2012-09-27 02:02 ./usr/include/
lrwxrwxrwx root/root         0 2012-09-27 02:02 ./usr/share/doc/gcc-multilib -> cpp
lrwxrwxrwx root/root         0 2012-09-27 02:02 ./usr/include/asm -> x86_64-linux-gnu/asm

On some Wheezy hosts in my net /usr/include/asm is a real directory,
even though gcc-multilib is installed:

# ls -al /usr/include/asm
total 20
drwxr-xr-x  2 root root  4096 Jul  3 09:26 .
drwxr-xr-x 43 root root 16384 Jul  3 14:35 ..

Reinstalling gcc-multilib doesn't help. There is no error
message, either:

# dpkg -i /var/cache/apt/archives/gcc-multilib_4%3a4.7.2-1_amd64.deb
(Reading database ... 170395 files and directories currently installed.)
Preparing to replace gcc-multilib 4:4.7.2-1 (using .../gcc-multilib_4%3a4.7.2-1_amd64.deb) ...
Unpacking replacement gcc-multilib ...
Setting up gcc-multilib (4:4.7.2-1) ...

# ls -al /usr/include/asm
total 20
drwxr-xr-x  2 root root  4096 Jul  3 09:26 .
drwxr-xr-x 43 root root 16384 Jul  3 14:35 ..

I don't know where this unwanted asm directory came from (upgrade
from Squeeze to Wheezy?), but the important point is that dpkg
neither complains about the conflict, nor does it replace the
empty directory. This makes dpkg unreliable.

If dpkg is unreliable, then what are the package signatures good for?


Regards
Harri

Hi!

I'm not sure which package signatures you're talking about. But, no, this
is very old “expected” behavior, it's documented both in the dpkg FAQ:

  <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Will_dpkg_replace_a_symlink_with_a_directory_or_vice_versa.3F>

or in debian-policy §6.6.4.

Thanks,
Guillem

Hi Guillem,

I can assure you that this is not expected. Instead of a symlink
there was an empty directory, breaking the development environment
on some of our build hosts.

If I got this right, then not taking care of the previous
/usr/include/asm directory it is a serious bug in gcc-multilib.
It should have provided a preinst script for that. Is this
correct?


Regards
Harri

Hi!

Perhaps expected was not the appropriate word. I didn't mean it in
the sense of what a user might intuitively expect, but what one might
expect from the relevant documentation, which is rather old.

Whoever provided or created that symlink, and then stopped doing so
should have cleaned after itself, yes.

Thanks,
Guillem