Debian Bug report logs - #793183
dpkg ignores symbolic link in gcc-multilib package

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Harald Dunkel <harald.dunkel@aixigo.de>

To: submit@bugs.debian.org

Subject: dpkg ignores symbolic link in gcc-multilib package

Date: Wed, 22 Jul 2015 09:27:14 +0200

Package: dpkg
Version: 1.16.16

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

Message #10 received at 793183@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Harald Dunkel <harald.dunkel@aixigo.de>, 793183@bugs.debian.org

Subject: Re: Bug#793183: dpkg ignores symbolic link in gcc-multilib package

Date: Wed, 22 Jul 2015 15:19:47 +0200

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

Message #21 received at 793183@bugs.debian.org (full text, mbox, reply):

From: Harald Dunkel <harald.dunkel@aixigo.de>

To: Guillem Jover <guillem@debian.org>, 793183@bugs.debian.org

Subject: Re: Bug#793183: dpkg ignores symbolic link in gcc-multilib package

Date: Thu, 23 Jul 2015 10:36:33 +0200

Hi Guillem,

On 07/22/15 15:19, Guillem Jover wrote:
>>
>> 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:
> 

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.

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

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

Message #26 received at 793183@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Harald Dunkel <harald.dunkel@aixigo.de>, 793183@bugs.debian.org

Subject: Re: Bug#793183: dpkg ignores symbolic link in gcc-multilib package

Date: Wed, 12 Aug 2015 18:48:44 +0200

Hi!

On Thu, 2015-07-23 at 10:36:33 +0200, Harald Dunkel wrote:
> On 07/22/15 15:19, Guillem Jover wrote:
> >>
> >> 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:
> 
> 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.

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.

> >   <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Will_dpkg_replace_a_symlink_with_a_directory_or_vice_versa.3F>
>
> 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?

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

Thanks,
Guillem

Send a report that this bug log contains spam.