Arch Linux

#1) It will obliterate nothing unless you are very stupid and use -f. Pacman will complain otherwise. Arch is pure 64-bit so its 64 bit libraries are in /lib. We have /lib32 for 32-bit libraries. The /lib64 "directory" is only provided for compatibility with binary blobs and should have only ever contained symlinks to the linker from /lib. Summary: Not a bug.

#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.

I could confirm that at #1) pacman complain. But if you made such a change why don't you update "Main page" to give instructions what to do in that case?
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.

Pacman can update an _empty_ directory with a symlink. And the only package in our repos that has files in /lib64 is glibc so there directory will be empty unless you have done something to it on your system. You have to deal with unsupported packages or manually created files yourself.

FHS 2.3 says, in section 6.1.5:

"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.

Arch x86_64 has always been a pure 64 bit implementation - it puts its libraries in {/usr,}/lib where all good libraries should go. Arch x86_64 has never followed the rotting piece of garbage that is the FHS, and we are not the only distribution with this setup. ***cough*** Debian ***cough***


Feel free to build your own glibc... but you will have fun tomorrow when /lib becomes a symlink to /usr/lib.

Debian has /lib32 but debian supports non-Linux systems (FHS only requires /lib64 for Linux). They put their essential libraries in /lib32, which is sane compared to /usr/lib32. 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. But the way Arch is now doesn't make any sense at all.

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.

> If you symlink /lib to /usr/lib no system that mounts /usr will boot.

You are an idiot.

Personal attacks... great.

Buh-bye.

It's too bad there's nothing that can be done about early mounting /usr when its on a separate partition.

http://mailman.archlinux.org/pipermail/arch-general/2012-January/024124.html
https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partition

> They put their essential libraries in /lib32, which is sane compared to /usr/lib32.

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.

> There is no essential 32 bit libraries on a 64 bit system.

This is where you disagree with both LHS and Debian.

Wondering if this is the reason of my no longer working archlinux + testing, I tried to report in bug #30587.

The glibc maintainer has gone postal. Expect worse in upcoming glibc updates.

See also,
#30586
#30587
#30588
#30593