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

[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

[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

[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

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

[Vincent Lefevre]

Package: gcc-multilib
Version: 4:7.1.0-2
Severity: wishlist

gcc-multilib currently provides two independent features:
1. the /usr/include/asm symbolic link (which has nothing to do with a
   specific GCC version);
2. depends on the default GCC version (currently via gcc-7-multilib).

Because on that, one currently has the following issue if one wants
to install a non-default multilib GCC version, e.g. gcc-6-multilib:

1. gcc-6-multilib (like the other gcc-X-multilib packages) depends on
   libc6-dev-i386.
2. libc6-dev-i386 recommends[*] gcc-multilib.
3. gcc-multilib depends on the default multilib GCC version, currently
   gcc-7-multilib.

[*] currently suggests, but this will be reverted to recommends
because the /usr/include/asm symbolic link is needed any
gcc-X-multilib compiler:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865429#20

So, installing gcc-6-multilib has the effect to install gcc-7-multilib,
while the user may just want version 6.

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.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-multilib depends on:
ii  cpp 4:7.1.0-2
ii  gcc 4:7.1.0-2
ii  gcc-7-multilib  7.1.0-13
ii  linux-libc-dev  4.11.11-1

gcc-multilib recommends no packages.

gcc-multilib suggests no packages.

-- no debconf information