Control: forcemerge 406715 -1 Control: severity -1 wishlist Hi!
On Wed, 2015-07-22 at 09:27:14 +0200, Harald Dunkel wrote: > Package: dpkg > Version: 1.16.16 > > gcc-multilib (4:4.7.2-1, amd64) provides a symbolic link for > /usr/include/asm > On some Wheezy hosts in my net /usr/include/asm is a real directory, > even though gcc-multilib is installed: > 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) ... > 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? 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
