Arch Linux glibc Update

Arch Linux has made a rather big change to the file system recently and has moved the files in the /lib directory to the /usr/lib directory and /lib is now a symlink to usr/lib. You can get an overview of the change here and here. Both of these pages give instructions and possible issue resolutions for most case's.

However, as searching the Arch Forums on glibc will show, the resolutions outlined in the above documents do not always work. There are a large number of users that have had problems due to various files that are left in the /lib directory. To quote Zamboniman from the Arch Forums "This has been one of the more frustrating upgrades in my history with Arch." After running pacman -Syu recently I discovered I was one of these people!

I have now resolved my issue and wanted to detail it incase it is any help to anyone else still struggling with the issue. For a little background I am running Arch 64bit.

NOTE DO NOT USE --force WITH pacman IN ANY FORM TO RESOLVE THIS ISSUE AND DO NOT DELETE OR MOVE ANY FILES MANUALLY.

First, I followed the recommended update method and ran pacman -Syy and then pacman -Syu --ignore glibc. This brought the system up to date and I then ran pacman -Su which will update glibc. However, like so many others, I got the following error output :

error: failed to commit transaction (conflicting files) glibc: /lib exists in filesystem

This, apparently, is caused by files remaining in the /lib directory. As per a number of the suggested solutions I then ran find /lib -exec pacman -Qo -- {} + which lists who owns the files left in the /lib directory. As recommended in one forum post I started to look for files not owned by glibc. There was one file and that was lib32-glibc. A lot of the solutions suggested at this point to just delete the file or uninstall the program that it is installed by however, looking at the file version (2.15-10) I noticed that there was a newer version available. The file is installed from the Multilib repository and I was at a loss as to how it was not being updated. After a little more digging I found that the Multilib repository was commented out in the /etc/pacman.conf file. I uncommented the repository entry in the file and ran pacman -Syy and then pacman -Syu --ignore glibc and then ran pacman -Su.

This all appeared to work. As a final check I ran ls -ld /lib which should output lrwxrwxrwx 1 root root 7 Jul 7 11:09 /lib -> usr/lib which denotes that everything has worked.

This solution will probably not fix everyone's issue with regard to this update and the links below are to forum threads that helped me track down the solution to my problem

• https://bbs.archlinux.org/viewtopic.php?id=145006&p=1
• https://wiki.archlinux.org/index.php/DeveloperWiki:usrlib
• https://bbs.archlinux.org/viewtopic.php?pid=1129890 - This thread contains Zamboniman's excellent advice which appears to have helped a number of people with slightly different issues to mine.
• https://bbs.archlinux.org/viewtopic.php?id=109765 - Multilib related.

Now, to get on with playing with KDE 4.9!

Project Forking & MySql

This is an interesting article looking at the currently state of MySql since the take over by Oracle. It would seem a number of leading developers have now left (some even before Oracle arrived). There appear to be a number forks appearing and one of the original developers has now created the Open Database Alliance which aims to be a central hub for MySql and all derivatives including development, training and support.

This seems to be another example of how some open source projects go once they leave the control of the projects founder(s) or when a project gets to the size where many opinions are conflicting. As the above article mentions, glibc is currently suffering what appears to be a similar revolt as gcc suffered a number of years ago. People seem to be having "issues" with the glibc maintainer and some have gone so far as to file a bug against the maintainer. This, I don't think, is really the way to go and gives people ammo in the "OSS developers are rude, ignorant and unapproachable" argument which I find is, usually, the complete opposite of what I experience.

Whatever the outcome is both MySql and glibc appear to have interesting times ahead. Perhaps lessons can be learnt from these and previous projects that have suffered similar fates.