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

2017-08-14 Thread Aurelien Jarno
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

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



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

2017-08-14 Thread Vincent Lefevre
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.

> 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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



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

2017-08-14 Thread Aurelien Jarno
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.

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.

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