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