FS#30559 - [glibc] 2.16.0-1 PKGBUILD symlink /lib64 to /lib destroys /lib64 contents and breaks archiso build
Attached to Project:
Arch Linux
Opened by Brian BIdulock (bidulock) - Friday, 06 July 2012, 07:12 GMT
Last edited by Allan McRae (Allan) - Saturday, 07 July 2012, 23:54 GMT
Opened by Brian BIdulock (bidulock) - Friday, 06 July 2012, 07:12 GMT
Last edited by Allan McRae (Allan) - Saturday, 07 July 2012, 23:54 GMT
|
Details
Description:
In the PKGBUILD for glibc 2.16.0-1 the lines: mkdir ${pkgdir}/lib64 cd ${pkgdir}/lib64 ln -v -s ../lib/ld* . were changed to ln -s /lib ${pkgdir}/lib64 Bug #1: This obliterates the /lib64 directory and anything it contains when upgrading. The FHS says put 32-bit system binaries in /lib and 64-bit system binaries in /lib64. Any package complying to the FHS will have its 64-bit system libraries obliterated when glibc 2.16.0-1 updates on x86_64. After update compliant packages will no longer be able to place their 32-bit libs in /lib and their 64-bit libs in /lib64 because they are linked. Bug #2: glibc is part of base. Base needs to be installed before a chroot environment can be set up during an archiso build. Because an absolute path is substituted for relative paths, using pacman with an install root to install base packages for a chroot environment will result in the work/root-image/lib64 directory being linked to the build host's /lib directory when glibc 2.16.0-1 installs instead of work/root-image/lib64. Please change this back, or better still place all glibc 2.16.0 64-bit binaries into /lib64 instead of placing them in /lib and linking from /lib64 (only 32-bit binaries should in /lib). Also the lib32-glibc package should place its binaries in /lib instead of /usr/lib32 (/usr might not be available and yet there is nothing stopping a 32-bit binary requiring 32-bit glibc being present in /sbin or /bin). Steps to reproduce bug #1: * Place a file in /lib64 before upgrading to glibc 2.16.0-1 * Upgrade to glibc 2.16.0-1 * Observe that entire /lib64 directory contents are lost on upgrade Steps to reproduce bug #2: * Perform an archiso base build. * observe that ./work/root-image/lib64 links to /lib on the build system instead of in the work directory. |
This task depends upon
Closed by Allan McRae (Allan)
Saturday, 07 July 2012, 23:54 GMT
Reason for closing: Not a bug
Additional comments about closing: "The glibc maintainer has gone postal."
Saturday, 07 July 2012, 23:54 GMT
Reason for closing: Not a bug
Additional comments about closing: "The glibc maintainer has gone postal."
#2) Is a bug. The symlink should be to "lib" rather than "/lib". Is already fixed in a glibc that will be uploaded to testing in the next day.
Pacman is not able to owerwrite directory with a file even with --force (at least for me), so should this directory be removed manually before update?
By the way, lib64 in package also given with a full path "/lib64" instead of relative.
"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.
The 64-bit architecture IA64 must place 64-bit libraries in /lib.
Rationale:
This is a refinement of the general rules for /lib<qual> and /usr/lib<qual>. The architectures PPC64, s390x, sparc64 and AMD64 support support [sic] both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on the architecture."
I don't know what you mean by "pure 64-bit", Arch does not even support ia64. Because #1 deviates from the Linux standard, it is a bug according to the Arch FAQ for bug reporting. In fact, the only reason you need to link /lib64 to /lib is because you are placing libraries in the wrong directory in the first place. All software, including glibc, expects 64-bit binaries in /lib64 and 32-bit binaries in /lib on x86_64 (AMD64).
I reported it because the change is going to affect a lot of others. Sure there are no other essential libraries in core that fill these directories, but that doesn't cover AUR or derivative distros, nor anybody else just wanting to develop for Arch. Also, according to the FHS placing 32-bit essential libraries in /usr/lib32 is simply wrong too. Programs expect them in /lib. Runtime linker paths coded into shared libraries and binaries built on LSB compliant systems will not work.
There is no good reason offerred as to why Arch should choose not to comply with the FHS for Linux. It is in fact easier to do it the right (FHS) way. We would not need a lib32-glibc package because the i686 glibc package would do (it already places 32-bit binaries in /lib). All that is required is for the x86_64 glibc package to place its binaries in /lib64 and the lib32-glibc package could go. This would be fully compliant with the FHS and is the way that all other distros do it on x86_64 anyway.
At any rate, I really don't care, I just wanted to report it because I noticed it and thought that Arch cared about following Linux standards and avoiding having to deal with the incompatibilities with upstream that comes from not following adopted Linux standards. But it seems you don't care. Just as well. The nice thing about the ABS is that I can easily fork the glibc build for my own systems. It will just mean 41 forked packages instead of 40.
Feel free to build your own glibc... but you will have fun tomorrow when /lib becomes a symlink to /usr/lib.
If you symlink /lib to /usr/lib no system that mounts /usr will boot.
If you want to chase people away from Arch, keep it up.
You are an idiot.
Buh-bye.
http://mailman.archlinux.org/pipermail/arch-general/2012-January/024124.html
https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partition
There is no essential 32 bit libraries on a 64 bit system. So all essential 32 bit libraries are already in /lib32...
So...
>I wouldn't have a problem if you followed debian's approach, put 32-bit in /lib32 and /usr/lib32, put 64-bit in /lib and /usr/lib and symlink /lib64 to /lib and /usr/lib64 to /usr/lib
32 bin in /usr/lib32... check.
64 bit in /lib and /usr/lib... check
symlink /lib64 to /lib... check (hang on, I thought you had an issue with that...)
symlink /usr/lib64 to /usr/lib.. no. Useless symlink that no software every expects.
So there is no problem here apart from /lib64 being a symlink to "/lib" instead of "lib" which is fixed in the glibc build that is currently being tested before upload.
This is where you disagree with both LHS and Debian.
See also,
#30586
#30587
#30588
#30593