Archlinux Update log: migrate/lib to/usr/lib

One change in this update is that the/lib directory and the/usr/lib directory are merged. After the update, the/lib directory will be just a link pointing to/usr/lib. As this change involves a lot of software, the Archlinux website provides dedicated upgrade guidance.

sudo pacman -Syu --ignore glibcsudo pacman -Su

As mentioned in the Guide, the second command still reports an error in/lib. Run the following command to check which directories do not belong to glibc.

find /lib -exec pacman -Qo -- {} +sudo rm -rf /lib/modules

I found some files in the/lib/modules directory and its sub-directories. I checked that I didn't have a self-compiled kernel module, So I deleted it directly.

So far, the upgrade is successful.

Why merge?

Maybe you are the same as me. There are 100,000 reasons in your mind: Why are you merging? What are the benefits of merging? What should I do with my/usr partitioning separately? Has the FHS standard changed? With these question marks, I went to Google Niang. After several rounds, Google Niang finally confided the truth: this change was led by Fedora, and there was a description on freedesktop. The key points are as follows:

More than/lib,/bin,/sbin, And/lib64 will be merged to the corresponding directory under/usr. Archlinux is integrated with/lib and/lib64, which point to/usr/lib instead of/usr/lib64 in the description. After the merger, the compatibility will be increased to benefit software maintenance personnel.

• Different wrapper in Linux and Unix systems sometimes puts the same program in different directories. Now/bin, or/usr/bin, is not a problem. I think the path hard encoding should happen more in the script. Why not simply merge/sbin and/bin, but I cannot see the need to keep them.
• Solaris 11 has implemented a similar merger, followed up by Linux, which is consistent with the major commercial Unix systems. It is interesting that Solaris started to do this 15 years ago. In fact, on SysV Unix,/bin has always been a link to/usr/bin.

The merger facilitates system publishers to put system resources in a unified/usr directory and release a separate read-only/usr partition. Multiple customer systems can be easily shared through the network or locally, the customer system will mainly include the user's configuration file, which can be smaller. In this regard, I would like to say that it is obviously affected by smart devices such as Android. Open-source is to give you full control over your devices. If we have to wait for them to give us jailbreak or root tools again and again to free/usr writable permissions, I would like to ask if this is in line with the open source spirit? Vendors will say, but they will lock/usr for security reasons. Indeed, as mobile devices such as mobile phones become increasingly indispensable, security issues cannot be ignored. I think in the future, is it possible that GPL4 will require Linux vendors to provide a security tool that allows users to unlock their mobile phones.

Someone asked how to start the system if/usr partition is not mounted? The separate/bin and/lib directories allow us to have a minimal first aid system. The answer is that all these are now handed over to initrd.

In general, I personally feel that this change is mostly driven by manufacturers rather than community users. The above reasons are not very convincing for individual users like me, at least I have never encountered a situation where the executable program cannot be found due to/bin,/usr/bin confusion. Even if I occasionally encounter it, I want to create a link in the directory, you can easily modify the script. Of course, I have no objection. It doesn't matter to me, but I 'd better change FHS first.