[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#872054: gcc-multilib: installation of gcc-X-multilib should not yield the installation of the default gcc

On 2017-08-14 19:40, Vincent Lefevre wrote:
> On 2017-08-14 18:21:07 +0200, Aurelien Jarno wrote:
> > On 2017-08-13 23:00, Vincent Lefevre wrote:
> > > Something needs to be done to avoid that. Shouldn't the
> > > /usr/include/asm symbolic link be provided either by libc6-dev-i386
> > > or by the individual gcc-X-multilib packages, for instance? In such a
> > > case, libc6-dev-i386 would no longer need to recommend gcc-multilib.
> > 
> > First of all I believe moving this symlink to libc6-dev-i386 is the
> > wrong thing to do, while libc6 needs this symlink you also need it for
> > building packages with another libc.
> I don't think this is a problem since, e.g. for amd64, the
> gcc-X-multilib packages depend on libc6-dev-i386, so that
> you'll get the symlink.

Still my point is that the libc should not be responsible for providing
the linux kernel headers compatibility links for multilib.

> > In addition this also won't work for architectures with triarch support,
> > as it would mean for example that both libc6-dev-i386 and libc6-dev-x32
> > need to provide the symlink. This would make them not coinstallable
> > anymore.
> Do you mean that dpkg doesn't support coinstallation when the
> symlink is the *same*?
> For instance, with amd64, the symlink is:
>   /usr/include/asm -> x86_64-linux-gnu/asm
> thus both libc6-dev-i386:amd64 and libc6-dev-x32:amd64 would have
> this same symlink.

It seems support has been added to dpkg to support that.


Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Reply to: