Processed: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Processing commands for [EMAIL PROTECTED]: reassign 387446 general Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS Bug reassigned from package `glibc' to `general'. retitle 387446: amd64 system not compliant with FHS Unknown command or malformed arguments to command. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
reassign 387446 general retitle 387446: amd64 system not compliant with FHS thanks Goswin von Brederlow wrote: Aurelien Jarno [EMAIL PROTECTED] writes: On Thu, Sep 14, 2006 at 01:28:24PM -0700, Steve Langasek wrote: severity 387446 normal thanks On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote: I set this to serious because it sort of violates a MUST directive in the FHS: Your changes also violate the FHS, as the system libraries should be in /lib. Two things. First it doesn't move the libc6 out of /lib. Secondly not Which is really bad. At least the current way of doing that is coherent. With your proposal the libraries are compiled for /lib64 and are put in /lib. You are still violating the FHS the same way because the libraries are at the same exact location. But this is also totally incoherent. With the current situation the libraries are compiled for /lib and are put in /lib. This violates the FHS, but it is coherent. for amd64. That is a special case made so i386 binaries can stay the same on amd64. Only Debian has deviated from that setup as vorlon said in his next sentence: This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. There is currently no way to do a plain amd64 distribution without violating the FHS. So I don't really want to make changes that probably have side effects just for violating the FHS another way. The FHS sees amd64 as a 64bit extension of i386, just like ppc, sparc, mips, s390 have their 64bit extensions. In that sense a plain amd64 distribution would mean that you have no libraries in /lib or /usr/lib since you have no 32bit libs at all. If that violates something in the FHS then too bad. But does that mean we should just violate more? My opinion is that the FHS should be changed. Unfortunately nobody seems to read the FHS mailing list... Multiarch dirs will not happen for etch. Maybe some day the proposal will be adopted. But Debian not implementing it doesn't really help the case. That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. Agreed. Can we at least put it into sid so you can see that nothing changes? No, because that would remove us the possibility to make fixes in testing. We are planning to do another upload with documentation fixes. Also packages that go into testing are build against the glibc in sid. This could lead to broken package going to testing. Actually there is nothing wrong with the glibc, it is perfectly coherent with the other packages on amd64, even if it violates the FHS. If you want to change it we have to stay coherent and also change all the others packages. I am therefore reassigning this bug to general. A global decision as to be taken. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Steve Langasek [EMAIL PROTECTED] writes: severity 387446 normal thanks On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote: I set this to serious because it sort of violates a MUST directive in the FHS: This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. It is an unneccessary one. That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. The fiddling only changes the compiled in path. But the lib64 link makes that irelevant for Debian. Both locations end in the same file. The risk less than some user linking or bind mounting /usr/lib to another location and that is already supported and deemed save. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Aurelien Jarno [EMAIL PROTECTED] writes: On Thu, Sep 14, 2006 at 01:28:24PM -0700, Steve Langasek wrote: severity 387446 normal thanks On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote: I set this to serious because it sort of violates a MUST directive in the FHS: Your changes also violate the FHS, as the system libraries should be in /lib. Two things. First it doesn't move the libc6 out of /lib. Secondly not for amd64. That is a special case made so i386 binaries can stay the same on amd64. Only Debian has deviated from that setup as vorlon said in his next sentence: This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. There is currently no way to do a plain amd64 distribution without violating the FHS. So I don't really want to make changes that probably have side effects just for violating the FHS another way. The FHS sees amd64 as a 64bit extension of i386, just like ppc, sparc, mips, s390 have their 64bit extensions. In that sense a plain amd64 distribution would mean that you have no libraries in /lib or /usr/lib since you have no 32bit libs at all. If that violates something in the FHS then too bad. But does that mean we should just violate more? My opinion is that the FHS should be changed. Unfortunately nobody seems to read the FHS mailing list... Multiarch dirs will not happen for etch. Maybe some day the proposal will be adopted. But Debian not implementing it doesn't really help the case. That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. Agreed. Can we at least put it into sid so you can see that nothing changes? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Package: glibc Version: 2.3.6.ds1-4 Severity: serious Tags: patch Hi, the standard location for libraries on amd64 is (/usr)/lib64 but glibc is build for (/usr)/lib. In most cases this makes no difference but there are some: 1) Compatibility with other linux When you copy debians libc6 or static binaries to other linux systems then the location of plugins changes from /usr/lib to /usr/lib64 (/usr/lib/gconv/ becomes /usr/lib64/gconv/). 2) automatic conversion for multiarch The same thing happens here. The converter for multiarch deletes the (/usr)/lib64 link and changes (/usr)/lib to (/usr)/lib64 so the library does not conflict with its 32bit counterpart. Again /usr/lib/gconv/ becomes /usr/lib64/gconv/ and so on. The attached patch is a simple solution to the problem. Glibc on amd64 gets compiled for (/usr)/lib64 as the FHS/LSB specify for amd64 but before packaging it gets renamed to (/usr)/lib and (later) the lib64-lib links are put in place. This way it works everywhere. -- I set this to serious because it sort of violates a MUST directive in the FHS: http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html | /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) | | The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place | 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries | in /lib. It does not specificaly mention plugins but I hope you agree the same rational applies there for libc6. -- MfG Goswin -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-frosties-2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) diff -u glibc-2.3.6.ds1/debian/rules.d/build.mk glibc-2.3.6.ds1/debian/rules.d/build.mk --- glibc-2.3.6.ds1/debian/rules.d/build.mk +++ glibc-2.3.6.ds1/debian/rules.d/build.mk @@ -124,6 +124,15 @@ tar zcf $(CURDIR)/debian/locales-all/usr/lib/locales-all/supported.tar.gz -C $(CURDIR)/debian/tmp-libc/usr/lib/locale .; \ fi + # Move lib64 to lib on amd64 + if [ $(curpass) = libc ] [ $(DEB_HOST_ARCH) = amd64 ]; then \ + find debian/tmp-$(curpass); \ + mkdir -p debian/tmp-$(curpass)/lib debian/tmp-$(curpass)/usr/lib; \ + mv debian/tmp-$(curpass)/lib64/* debian/tmp-$(curpass)/lib; \ + mv debian/tmp-$(curpass)/usr/lib64/* debian/tmp-$(curpass)/usr/lib; \ + rmdir debian/tmp-$(curpass)/lib64 debian/tmp-$(curpass)/usr/lib64; \ + fi + # Remove ld.so from optimized libraries if [ $(curpass) != libc ] [ $(call xx,configure_build) = $(call xx,configure_target) ]; then \ rm -f debian/tmp-$(curpass)/$(call xx,slibdir)/ld*.so* ; \ diff -u glibc-2.3.6.ds1/debian/sysdeps/amd64.mk glibc-2.3.6.ds1/debian/sysdeps/amd64.mk --- glibc-2.3.6.ds1/debian/sysdeps/amd64.mk +++ glibc-2.3.6.ds1/debian/sysdeps/amd64.mk @@ -2,8 +2,8 @@ libc_MIN_KERNEL_SUPPORTED = 2.6.0 libc_add-ons = nptl $(add-ons) libc_extra_cflags = -O3 -g1 -libc_slibdir = /lib -libc_libdir = /usr/lib +libc_slibdir = /lib64 +libc_libdir = /usr/lib64 libc_rtlddir = /lib64 # /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302. diff -u glibc-2.3.6.ds1/debian/changelog glibc-2.3.6.ds1/debian/changelog --- glibc-2.3.6.ds1/debian/changelog +++ glibc-2.3.6.ds1/debian/changelog @@ -1,3 +1,11 @@ +glibc (2.3.6.ds1-4a0.ql.0.1) unstable; urgency=low + + * sysdeps/amd64.mk: Set libc_slibdir /lib64 and libc_libdir to /usr/lib64 + * rules.d/build.mk: on amd64 rename debian/tmp-libc/lib64 to lib +and debian/tmp-libc/usr/lib64 to lib + + -- Goswin von Brederlow [EMAIL PROTECTED] Mon, 11 Sep 2006 16:45:24 +0200 + glibc (2.3.6.ds1-4) unstable; urgency=low [ Aurelien Jarno ]
Processed: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Processing commands for [EMAIL PROTECTED]: severity 387446 normal Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS Severity set to `normal' from `serious' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
severity 387446 normal thanks On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote: I set this to serious because it sort of violates a MUST directive in the FHS: This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
On Thu, Sep 14, 2006 at 01:28:24PM -0700, Steve Langasek wrote: severity 387446 normal thanks On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote: I set this to serious because it sort of violates a MUST directive in the FHS: Your changes also violate the FHS, as the system libraries should be in /lib. This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. There is currently no way to do a plain amd64 distribution without violating the FHS. So I don't really want to make changes that probably have side effects just for violating the FHS another way. My opinion is that the FHS should be changed. Unfortunately nobody seems to read the FHS mailing list... That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. Agreed. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
