Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
Hi, On Mon, 02 Jun 2014, Aurelien Jarno wrote: Alternatively, we can create an empty package called for example multiarch-no-foreign, which is arch:any and Multi-arch: none. That way all packages which should not be installed as foreign architecture can depend on this one. What do you think? Well it won't work, because installing libc6-amd64:i386 will pull multiarch-no-foreign:i386, and thus the whole set will be installable. This can be solved by ensuring that it's installed in sync with dpkg, eg by letting dpkg depends on multiarch-no-foreign, no? This would be a supplementary hassle to cross-grade a system from one arch to another though. Or maybe we don't need the dependency but we can just get it installed during debootstrap? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603070038.gb29...@x230-buxy.home.ouaza.com
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
Hi! On Mon, 2014-05-19 at 15:56:14 +0200, Aurelien Jarno wrote: On Mon, May 19, 2014 at 02:01:15PM +0200, Jakub Wilk wrote: * Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 13:28: So following your way, it would be exactly the same for libc6:sparc. libc6-i386 also provides /lib/ld-linux.so.2. It should be co-installable with libc6:i386, but libc6:sparc should not be co-installable with libc6:i386 or libc6-i386. Oh, right. Couldn't the biarch packages die already? :) Unfortunately, as long as we keep GCC, we will need them, even if they are a pain. Actually, why? I guess I might be missing something obvious, but even if GCC wants to preserve the bi/triarch stuff (which I think is a bad idea), why does glibc need to keep them in the current form as well? Couldn't they be switched to empty packages depending on the actual packages from the other arch, using either cross-arch dependencies or the arch-annotated provides or similar? Or alternatively be switched to native packages, or be simply provided by the native package, similar to how the ia32-libs stuff got transitioned? Thanks, Guillem -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603112113.ga...@gaara.hadrons.org
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
On Tue, Jun 03, 2014 at 09:00:38AM +0200, Raphael Hertzog wrote: Hi, On Mon, 02 Jun 2014, Aurelien Jarno wrote: Alternatively, we can create an empty package called for example multiarch-no-foreign, which is arch:any and Multi-arch: none. That way all packages which should not be installed as foreign architecture can depend on this one. What do you think? Well it won't work, because installing libc6-amd64:i386 will pull multiarch-no-foreign:i386, and thus the whole set will be installable. This can be solved by ensuring that it's installed in sync with dpkg, eg by letting dpkg depends on multiarch-no-foreign, no? That indeed would do it. This would be a supplementary hassle to cross-grade a system from one arch to another though. That's true. This point to the question: how is the main architecture of a system determined, and how is happening the switch between the main and the foreign architecture in a cross-grade procedure? This might be a problem even if we choose to update the multiarch specification to disallow foreign packages. Or maybe we don't need the dependency but we can just get it installed during debootstrap? If it only installed during deboostrap with nothing depending on it, it can be reinstalled for another architecture. apt might even be smart enough to suggest that. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603183939.gj5...@hall.aurel32.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
On Tue, Jun 03, 2014 at 01:21:13PM +0200, Guillem Jover wrote: Hi! On Mon, 2014-05-19 at 15:56:14 +0200, Aurelien Jarno wrote: On Mon, May 19, 2014 at 02:01:15PM +0200, Jakub Wilk wrote: * Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 13:28: So following your way, it would be exactly the same for libc6:sparc. libc6-i386 also provides /lib/ld-linux.so.2. It should be co-installable with libc6:i386, but libc6:sparc should not be co-installable with libc6:i386 or libc6-i386. Oh, right. Couldn't the biarch packages die already? :) Unfortunately, as long as we keep GCC, we will need them, even if they are a pain. Actually, why? I guess I might be missing something obvious, but even if GCC wants to preserve the bi/triarch stuff (which I think is a bad idea), why does glibc need to keep them in the current form as well? GCC needs to the libc packages to build the bi/triarch support. Couldn't they be switched to empty packages depending on the actual packages from the other arch, using either cross-arch dependencies or the arch-annotated provides or similar? Or alternatively be switched to native packages, or be simply provided by the native package, similar to how the ia32-libs stuff got transitioned? There are multiple problems with that: - Currently gcc does not look in the multiarch path for the multilib case. This can probably be fixed though. - Cross-architecture dependencies are not supported by the build infrastructure. - We don't always have the equivalent bi/triarch architecture in debian. We basically have it for i386/amd64, but we don't have it for mipsn32, mipsn32el, mips64, mips64el, s390, ppc64, sparc64. There were some discussion about having a minimal set of packages for these architectures a few years ago, but it requires a lot of changes in the infrastructure and also at the packaging level. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603184600.gk5...@hall.aurel32.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
On Fri, May 30, 2014 at 08:42:53PM +0200, Aurelien Jarno wrote: On Wed, May 28, 2014 at 06:04:22PM +0200, Aurelien Jarno wrote: On Mon, May 19, 2014 at 12:09:28PM -0700, Jonathan Nieder wrote: Aurelien Jarno wrote: As a subsidiary question, do you know how to prevent libc6-amd64:i386 to be installed on a native amd64 system, but allow it on an i386 system, even with libc6:amd64 already installed? Use Conflicts against dpkg:amd64, maybe. :( I have been looking at this issue a bit more in details. libc biarch packages have never been designed with multiarch in mind, and thus they are not tagged as multiarch packages (implicit Multi-arch: none). However since multiarch, as the Multi-arch: field only concerns dependencies, and that such packages do not have Depends: beside the libc6 one, they are suddenly installable as foreign packages. That's why we suddenly have for example conflicts issue between libc6-dev-i386 and libc6-dev-mips64 (#702962) or libc6-dev-i386 and libc6-dev-mips64 (#702962), or why people are allowed to install libc6-amd64 on their amd64 system. I therefore wonder if we can add a new value for the Multi-arch: field like forbidden, to prevent a foreign package to be installed on a system. Otherwise it looks like we'll have to go with a long list of Conflicts... Alternatively, we can create an empty package called for example multiarch-no-foreign, which is arch:any and Multi-arch: none. That way all packages which should not be installed as foreign architecture can depend on this one. What do you think? Well it won't work, because installing libc6-amd64:i386 will pull multiarch-no-foreign:i386, and thus the whole set will be installable. We definitely do want to forbid things like installing gdb64:i386 or strace64:i386 on an amd64 system, or more horrible things like trying to install libc6-dev-x32:am64 on an i386 system. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602180336.ga11...@hall.aurel32.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
On Wed, May 28, 2014 at 06:04:22PM +0200, Aurelien Jarno wrote: On Mon, May 19, 2014 at 12:09:28PM -0700, Jonathan Nieder wrote: Aurelien Jarno wrote: As a subsidiary question, do you know how to prevent libc6-amd64:i386 to be installed on a native amd64 system, but allow it on an i386 system, even with libc6:amd64 already installed? Use Conflicts against dpkg:amd64, maybe. :( I have been looking at this issue a bit more in details. libc biarch packages have never been designed with multiarch in mind, and thus they are not tagged as multiarch packages (implicit Multi-arch: none). However since multiarch, as the Multi-arch: field only concerns dependencies, and that such packages do not have Depends: beside the libc6 one, they are suddenly installable as foreign packages. That's why we suddenly have for example conflicts issue between libc6-dev-i386 and libc6-dev-mips64 (#702962) or libc6-dev-i386 and libc6-dev-mips64 (#702962), or why people are allowed to install libc6-amd64 on their amd64 system. I therefore wonder if we can add a new value for the Multi-arch: field like forbidden, to prevent a foreign package to be installed on a system. Otherwise it looks like we'll have to go with a long list of Conflicts... Alternatively, we can create an empty package called for example multiarch-no-foreign, which is arch:any and Multi-arch: none. That way all packages which should not be installed as foreign architecture can depend on this one. What do you think? -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530184253.gf31...@hall.aurel32.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
On Mon, May 19, 2014 at 12:09:28PM -0700, Jonathan Nieder wrote: Aurelien Jarno wrote: As a subsidiary question, do you know how to prevent libc6-amd64:i386 to be installed on a native amd64 system, but allow it on an i386 system, even with libc6:amd64 already installed? Use Conflicts against dpkg:amd64, maybe. :( I have been looking at this issue a bit more in details. libc biarch packages have never been designed with multiarch in mind, and thus they are not tagged as multiarch packages (implicit Multi-arch: none). However since multiarch, as the Multi-arch: field only concerns dependencies, and that such packages do not have Depends: beside the libc6 one, they are suddenly installable as foreign packages. That's why we suddenly have for example conflicts issue between libc6-dev-i386 and libc6-dev-mips64 (#702962) or libc6-dev-i386 and libc6-dev-mips64 (#702962), or why people are allowed to install libc6-amd64 on their amd64 system. I therefore wonder if we can add a new value for the Multi-arch: field like forbidden, to prevent a foreign package to be installed on a system. Otherwise it looks like we'll have to go with a long list of Conflicts... -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140528160422.gi5...@hall.aurel32.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
* Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 12:25:
We currently have a problem with the libc{0.1,0.3,6,6.1} packages,
which are marked as Multiarch:same, but are in practice not
co-installable due to the ELF interpreter path being the same on
various architectures. For example libc6:i386 and libc6:sparc are not
co-installable, causing dpkg to exit complaining onifile overwrite.
Sounds like a job for Provides+Conflicts+Replaces.
Here is the list of the different ELF interpreters for the various
architectures we have in Debian or floating around:
i386/lib/ld-linux.so.2
Provides: lib-ld-linux-so-2
Conflicts: lib-ld-linux-so-2
Replaces: lib-ld-linux-so-2
hppa/lib/ld.so.1
m68k/lib/ld.so.1
mips/lib/ld.so.1
s390/lib/ld.so.1
Provides: lib-ld-so-1
Conflicts: lib-ld-so-1
Replaces: lib-ld-so-1
amd64 /lib64/ld-linux-x86-64.so.2
Provides: lib64-ld-linux-x86-64-so-2
Conflicts: lib64-ld-linux-x86-64-so-2
Replaces: lib64-ld-linux-x86-64-so-2
... and so on.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140519111636.gb8...@jwilk.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
On Mon, May 19, 2014 at 01:16:36PM +0200, Jakub Wilk wrote:
* Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 12:25:
We currently have a problem with the libc{0.1,0.3,6,6.1} packages,
which are marked as Multiarch:same, but are in practice not
co-installable due to the ELF interpreter path being the same on
various architectures. For example libc6:i386 and libc6:sparc are
not co-installable, causing dpkg to exit complaining onifile
overwrite.
Sounds like a job for Provides+Conflicts+Replaces.
Here is the list of the different ELF interpreters for the various
architectures we have in Debian or floating around:
i386/lib/ld-linux.so.2
Provides: lib-ld-linux-so-2
Conflicts: lib-ld-linux-so-2
Replaces: lib-ld-linux-so-2
So following your way, it would be exactly the same for libc6:sparc.
libc6-i386 also provides /lib/ld-linux.so.2. It should be co-installable
with libc6:i386, but libc6:sparc should not be co-installable with
libc6:i386 or libc6-i386.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140519112813.gd5...@hall.aurel32.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
* Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 13:28: i386/lib/ld-linux.so.2 Provides: lib-ld-linux-so-2 Conflicts: lib-ld-linux-so-2 Replaces: lib-ld-linux-so-2 So following your way, it would be exactly the same for libc6:sparc. libc6-i386 also provides /lib/ld-linux.so.2. It should be co-installable with libc6:i386, but libc6:sparc should not be co-installable with libc6:i386 or libc6-i386. Oh, right. Couldn't the biarch packages die already? :) If they can't, I suppose you can implement cross-architecture conflicts with plain conflicts against virtual packages: Package: libc6 Architecture: i386 Provides: libc6-on-i386 Conflicts: libc6-on-sparc, ... Package: libc6-i386 Architecture: amd64 Conflicts: libc6-on-sparc, ... Package: libc6 Architecture: sparc Provides: libc6-on-sparc Conflicts: libc6-on-i386, libc6-i386, ... -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140519120115.ga2...@jwilk.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
On Mon, May 19, 2014 at 02:01:15PM +0200, Jakub Wilk wrote: * Aurelien Jarno aurel...@aurel32.net, 2014-05-19, 13:28: i386/lib/ld-linux.so.2 Provides: lib-ld-linux-so-2 Conflicts: lib-ld-linux-so-2 Replaces: lib-ld-linux-so-2 So following your way, it would be exactly the same for libc6:sparc. libc6-i386 also provides /lib/ld-linux.so.2. It should be co-installable with libc6:i386, but libc6:sparc should not be co-installable with libc6:i386 or libc6-i386. Oh, right. Couldn't the biarch packages die already? :) Unfortunately, as long as we keep GCC, we will need them, even if they are a pain. If they can't, I suppose you can implement cross-architecture conflicts with plain conflicts against virtual packages: Package: libc6 Architecture: i386 Provides: libc6-on-i386 Conflicts: libc6-on-sparc, ... Package: libc6-i386 Architecture: amd64 Conflicts: libc6-on-sparc, ... Package: libc6 Architecture: sparc Provides: libc6-on-sparc Conflicts: libc6-on-i386, libc6-i386, ... Indeed we can encode the architecture in the Provides:. I guess we'll have script that... As a subsidiary question, do you know how to prevent libc6-amd64:i386 to be installed on a native amd64 system, but allow it on an i386 system, even with libc6:amd64 already installed? -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140519135614.ge5...@hall.aurel32.net
Re: [Multiarch-devel] cross-architecture conflicts or equivalent for libc packages
Aurelien Jarno wrote: As a subsidiary question, do you know how to prevent libc6-amd64:i386 to be installed on a native amd64 system, but allow it on an i386 system, even with libc6:amd64 already installed? Use Conflicts against dpkg:amd64, maybe. :( -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140519190928.go12...@google.com
