Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
On 2012-06-02 21:56 +0200, Aurelien Jarno wrote: On Sat, Jun 02, 2012 at 09:33:19PM +0200, Thibaut Girka wrote: On Sat, Jun 02, 2012 at 09:02:54PM +0200, Aurelien Jarno wrote: Your patch actually also makes libc0.1-dev, libc0.3-dev and libc6.1-dev m-a: same. You should also check for files in these packages. Oh, I didn't know about that. libc0.1-dev is ok. libc0.3-dev is ok since it's only available for one architecture. libc6.1-dev is ok too. Either we have to make them conflict one with another (that is libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc.), Note that this holds whether or not these packages are M-A: same. or we have to check for these packages as if they were a single one. This means they would need to have the same name (probably libc-dev) on all architectures. Cheers, Sven -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871ulw95oe@turtle.gmx.de
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
On Sun, Jun 03, 2012 at 10:10:41AM +0200, Sven Joachim wrote: On 2012-06-02 21:56 +0200, Aurelien Jarno wrote: On Sat, Jun 02, 2012 at 09:33:19PM +0200, Thibaut Girka wrote: On Sat, Jun 02, 2012 at 09:02:54PM +0200, Aurelien Jarno wrote: Your patch actually also makes libc0.1-dev, libc0.3-dev and libc6.1-dev m-a: same. You should also check for files in these packages. Oh, I didn't know about that. libc0.1-dev is ok. libc0.3-dev is ok since it's only available for one architecture. libc6.1-dev is ok too. Either we have to make them conflict one with another (that is libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc.), Note that this holds whether or not these packages are M-A: same. No, because these packages are architecture specific, so they are not co-installable. For example libc0.1-dev and libc6-dev might have conflicting files, but you can't install libc0.1-dev (kfreebsd-amd64 only) together with libc6-dev, unless they are marked M-A: same. or we have to check for these packages as if they were a single one. This means they would need to have the same name (probably libc-dev) on all architectures. Yes, thinking about that, either we want to make it fully multiarch, in that case all libc*-dev needs to be renamed to the same name, or we should add conflicts to prevent someone trying to install for example libc6.1-dev along with libc6-dev. -- Aurelien Jarno GPG: 1024D/F1BCDB73 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: http://lists.debian.org/20120603083931.gb22...@hall.aurel32.net
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
On 2012-06-03 10:39 +0200, Aurelien Jarno wrote: On Sun, Jun 03, 2012 at 10:10:41AM +0200, Sven Joachim wrote: On 2012-06-02 21:56 +0200, Aurelien Jarno wrote: Either we have to make them conflict one with another (that is libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc.), Note that this holds whether or not these packages are M-A: same. No, because these packages are architecture specific, so they are not co-installable. For example libc0.1-dev and libc6-dev might have conflicting files, but you can't install libc0.1-dev (kfreebsd-amd64 only) together with libc6-dev, unless they are marked M-A: same. Marking them M-A: same is not going to resolve these conflicts, because libc0.1-dev and libc6-dev still belong to different package sets, and with --force-overwrite you can install libc0.1-dev along libc6-dev already. or we have to check for these packages as if they were a single one. This means they would need to have the same name (probably libc-dev) on all architectures. Yes, thinking about that, either we want to make it fully multiarch, in that case all libc*-dev needs to be renamed to the same name, or we should add conflicts to prevent someone trying to install for example libc6.1-dev along with libc6-dev. Renaming seems to be the best long-term solution to me, but using conflicts is probably safer for wheezy. For instance, kfreebsd-kernel-headers:kfreebsd-i386 contains files clashing with both libc6:i386 and linux-libc-dev:i386: , | # dpkg -i --force-overwrite /var/cache/apt/archives/kfreebsd-kernel-headers_0.81_kfreebsd-i386.deb | (Reading database ... 13017 files and directories currently installed.) | Unpacking kfreebsd-kernel-headers (from .../kfreebsd-kernel-headers_0.81_kfreebsd-i386.deb) ... | dpkg: warning: overriding problem because --force enabled: | trying to overwrite '/usr/include/net/if_arp.h', which is also in package libc6-dev 2.13-32 | dpkg: warning: overriding problem because --force enabled: | trying to overwrite '/usr/include/net/ppp_defs.h', which is also in package libc6-dev 2.13-32 | dpkg: warning: overriding problem because --force enabled: | trying to overwrite '/usr/include/net/route.h', which is also in package libc6-dev 2.13-32 | dpkg: warning: overriding problem because --force enabled: | trying to overwrite '/usr/include/netatalk/at.h', which is also in package libc6-dev 2.13-32 | dpkg: warning: overriding problem because --force enabled: | trying to overwrite '/usr/include/netipx/ipx.h', which is also in package libc6-dev 2.13-32 | dpkg: warning: overriding problem because --force enabled: | trying to overwrite '/usr/include/linux/videodev2.h', which is also in package linux-libc-dev:i386 3.2.19-1 | Setting up kfreebsd-kernel-headers (0.81) ... ` Cheers, Sven -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq9g7og2@turtle.gmx.de
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
On Sun, Jun 03, 2012 at 11:08:13AM +0200, Sven Joachim wrote: On 2012-06-03 10:39 +0200, Aurelien Jarno wrote: On Sun, Jun 03, 2012 at 10:10:41AM +0200, Sven Joachim wrote: On 2012-06-02 21:56 +0200, Aurelien Jarno wrote: Either we have to make them conflict one with another (that is libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc.), Note that this holds whether or not these packages are M-A: same. No, because these packages are architecture specific, so they are not co-installable. For example libc0.1-dev and libc6-dev might have conflicting files, but you can't install libc0.1-dev (kfreebsd-amd64 only) together with libc6-dev, unless they are marked M-A: same. Marking them M-A: same is not going to resolve these conflicts, because libc0.1-dev and libc6-dev still belong to different package sets, and with --force-overwrite you can install libc0.1-dev along libc6-dev already. My point there is that given the package is that marking as M-A: same also implicitly means that the packager has verified that the package is not going to conflict with any other file. And if he/she failed to do so, it's a serious bug in the package, like we handled file conflicts bugs before the multiarch era. Currently theses packages are not marked as M-A: same, so it's not a bug in a package, but rather a bug in a multiarch specification allowing this. or we have to check for these packages as if they were a single one. This means they would need to have the same name (probably libc-dev) on all architectures. Yes, thinking about that, either we want to make it fully multiarch, in that case all libc*-dev needs to be renamed to the same name, or we should add conflicts to prevent someone trying to install for example libc6.1-dev along with libc6-dev. Renaming seems to be the best long-term solution to me, but using conflicts is probably safer for wheezy. For instance, kfreebsd-kernel-headers:kfreebsd-i386 contains files clashing with both libc6:i386 and linux-libc-dev:i386: I came to the same conclusion. -- Aurelien Jarno GPG: 1024D/F1BCDB73 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: http://lists.debian.org/20120603100802.gd4...@hall.aurel32.net
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
tags 666760 patch
thanks
Hi,
I was wondering why libc6-dev wasn't m-a: same, and I've decided to identify
which files
are arch-dependent but not in arch-qualified paths.
Here is what I've found using libc6-dev=2.13-32 binary packages from the
archive:
Searching for conflicts across the following architectures:
amd64, armel, armhf, i386, m68k, mips, mipsel, powerpc, s390, s390x,
sh4, sparc, sparc64
usr/include/a.out.h
44363cebe3e379d8aea5d368502ec4b4439c47eesparc, sparc64
131d2b9e51280468ac6736db94ff981a79364e29s390, sh4, amd64,
s390x, m68k, powerpc, i386, armel, armhf, mips, mipsel
usr/include/ieee754.h
8401e96f11f497f1dda32a878f50c7e74404defas390, s390x, sparc64,
sparc
d09e81c714db219efdca7f16f7e53fc6da6b94f9powerpc
41468caf81199e2bafafb8f8fbeb8be8be628f44mips, mipsel
ed7ef9b8e4fb8673d3bb53a259c49f434fcaadd1sh4, amd64, m68k, i386,
armel, armhf
I have no idea why the a.out.h file is different on sparc/sparc64, but,
although some unification should be possible without breaking the ABI,
I think having different ieee754.h files make sense, as different floating point
number representations are used on different architectures.
Thus, I think moving those files to arch-qualified paths would be enough for
wheezy.
That's what the attached patch does.
Regards,
Thibaut Girka.
Index: debian/control.in/libc
===
--- debian/control.in/libc (révision 5259)
+++ debian/control.in/libc (copie de travail)
@@ -26,6 +26,7 @@
Architecture: @archs@
Section: libdevel
Priority: optional
+Multi-Arch: same
Depends: @libc@ (= ${binary:Version}), libc-dev-bin (= ${binary:Version}), ${misc:Depends}, linux-libc-dev [linux-any], kfreebsd-kernel-headers (= 0.11) [kfreebsd-any], gnumach-dev [hurd-i386], hurd-dev (= 20080607-3) [hurd-i386]
Replaces: hurd-dev ( 20120408-3) [hurd-i386]
Recommends: gcc | c-compiler
Index: debian/rules.d/build.mk
===
--- debian/rules.d/build.mk (révision 5259)
+++ debian/rules.d/build.mk (copie de travail)
@@ -176,6 +176,8 @@
mv debian/tmp-$(curpass)/usr/include/gnu debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
mv debian/tmp-$(curpass)/usr/include/sys debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
mv debian/tmp-$(curpass)/usr/include/fpu_control.h debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
+ mv debian/tmp-$(curpass)/usr/include/a.out.h debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
+ mv debian/tmp-$(curpass)/usr/include/ieee754.h debian/tmp-$(curpass)/usr/include/$(DEB_HOST_MULTIARCH); \
fi
# For our biarch libc, add an ld.so.conf.d configuration; this
Index: debian/rules.d/stage1.mk
===
--- debian/rules.d/stage1.mk (révision 5259)
+++ debian/rules.d/stage1.mk (copie de travail)
@@ -65,6 +65,8 @@
mv $(DESTDIR)/usr/include/gnu $(DESTDIR)/usr/include/$(DEB_HOST_MULTIARCH)
mv $(DESTDIR)/usr/include/sys $(DESTDIR)/usr/include/$(DEB_HOST_MULTIARCH)
mv $(DESTDIR)/usr/include/fpu_control.h $(DESTDIR)/usr/include/$(DEB_HOST_MULTIARCH)
+ mv $(DESTDIR)/usr/include/a.out.h $(DESTDIR)/usr/include/$(DEB_HOST_MULTIARCH)
+ mv $(DESTDIR)/usr/include/ieee754.h $(DESTDIR)/usr/include/$(DEB_HOST_MULTIARCH)
$(call xx,extra_install)
touch $@
signature.asc
Description: Digital signature
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
tag 666760 - patch thanks On Sat, Jun 02, 2012 at 04:36:03PM +0200, Thibaut Girka wrote: tags 666760 patch thanks Hi, I was wondering why libc6-dev wasn't m-a: same, and I've decided to identify which files are arch-dependent but not in arch-qualified paths. Here is what I've found using libc6-dev=2.13-32 binary packages from the archive: Searching for conflicts across the following architectures: amd64, armel, armhf, i386, m68k, mips, mipsel, powerpc, s390, s390x, sh4, sparc, sparc64 Your patch actually also makes libc0.1-dev, libc0.3-dev and libc6.1-dev m-a: same. You should also check for files in these packages. -- Aurelien Jarno GPG: 1024D/F1BCDB73 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: http://lists.debian.org/20120602190254.gb13...@hall.aurel32.net
Processed: Re: Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
Processing commands for cont...@bugs.debian.org: tag 666760 - patch Bug #666760 [libc6-dev] [libc6-dev] Make libc6-dev multiarch-installable Removed tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 666760: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666760 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133866377929673.transcr...@bugs.debian.org
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
On Sat, Jun 02, 2012 at 09:02:54PM +0200, Aurelien Jarno wrote: Your patch actually also makes libc0.1-dev, libc0.3-dev and libc6.1-dev m-a: same. You should also check for files in these packages. Oh, I didn't know about that. libc0.1-dev is ok. libc0.3-dev is ok since it's only available for one architecture. libc6.1-dev is ok too. -- Aurelien JarnoGPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
On Sat, Jun 02, 2012 at 09:33:19PM +0200, Thibaut Girka wrote: On Sat, Jun 02, 2012 at 09:02:54PM +0200, Aurelien Jarno wrote: Your patch actually also makes libc0.1-dev, libc0.3-dev and libc6.1-dev m-a: same. You should also check for files in these packages. Oh, I didn't know about that. libc0.1-dev is ok. libc0.3-dev is ok since it's only available for one architecture. libc6.1-dev is ok too. Either we have to make them conflict one with another (that is libc0.1-dev and libc6-dev, libc0.3-dev with libc6-dev, etc.), or we have to check for these packages as if they were a single one. -- Aurelien Jarno GPG: 1024D/F1BCDB73 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: http://lists.debian.org/20120602195617.gc13...@hall.aurel32.net
Bug#666760: [libc6-dev] Make libc6-dev multiarch-installable
Package: libc6-dev Version: 2.13-27 Severity: normal --- Please enter the report below this line. --- I'd like to install zlib1g-dev:i386 to use zlib in a 32bit program. However, this is currently blocked by libc6-dev not being Multi-Arch: same, so I can not install it. --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-2-amd64 Debian Release: wheezy/sid 500 testing security.debian.org 500 testing ftp.de.debian.org --- Package information. --- Depends (Version) | Installed ==-+- libc6 (= 2.13-27) | libc-dev-bin (= 2.13-27) | linux-libc-dev | Recommends (Version) | Installed =-+-=== gcc | 4:4.6.2-4 OR c-compiler| Suggests (Version) | Installed ===-+-=== glibc-doc | manpages-dev| 3.35-0.1 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201204011711.52327.post+deb...@ralfj.de
