Given the number of unpleasant emails I have received over the last few days, it appears that people have forgotten what the purpose of the [testing] repo in Arch Linux is for. Wait for it…. testing packages! Who would have thought!

Now to clarify some things. While the [testing] repo is for testing, we do our best not to break things in it. In fact, the [staging] repo was set up to allow rebuilds to occur away from the main repos and allow [testing] to always be in a usable state. Also, many (maybe even most) of the Arch developers use the [testing] repo on their main computer. I know I use it on all of mine, including on my work laptop. So I really do not want things to break either. And of course, if I cause breakage, that limits my ability to yell at other people who break packages.

One of the common criticisms I got in my “fan mail” was that I did not do enough testing of the change that saw the /lib directory change into a symlink to /usr/lib . Perhaps the need for testing was why I put the package in the [testing] repo… But, also I did do a fair amount of testing of this update. I tested that pacman stopped the update when there was a file in /lib (or in a subdirectory of /lib ), both when the file was owned or unowned by a package. I checked that pacman -Syu --ignore glibc && pacman -Su worked from and old base install.

What I did not test was using pacman -Sf glibc to resolve a conflict, mainly because even with my low expectations on the general population’s intelligence, I did not expect Arch Linux [testing] users to be quite that incompetent. I also did not test having another package owning the /lib directory or a subdirectory within that folder but with no actual files in it (or having its files manually moved from in it). And I did not test upgrading from a more complete install that could have packages with versioned dependencies on glibc (which does not actually break the update but makes it a bit more difficult).

Now ignoring the usage of -Sf … the only case I did not test that actually causes breakage was an empty subdirectory in /lib or another package owning /lib with no actual files in there. That should never actually happen, but it appears people manually moved module or firmware files from /lib to /usr/lib without fixing thier packages, creating this situation. In both these cases, pacman would get to extracting the /lib symlink, see there was still a directory there and refuse to extract. That left people with a system looking for the linker in /lib , but it not being there. Annoying, but this situation is easily recoverable, even without a rescue CD.

You may ask why pacman did not detect those conflicts before attempting the extraction of the package. That would be a good question… It seems the situation of changing a directory to a file or symlink is not a very common operation and so was not very well tested in the (quite extensive) pacman test-suite. Also, a bug fix in pacman 4.0 (prevent removal of empty directories if they are owned by another package), will have caused this bug to be exposed much more frequently. A couple of patches to pacman and these conflicts are now caught prior to the upgrade taking place. These patches are now applied to our pacman package, so non-testing users will not be exposed to this issue.

So a couple of things to note… Firstly, this was not a bug in the glibc package. Secondly, I fixed the bugs in the pacman conflict checking code. So… just maybe… I am not as “incompetent” as the emails I received claimed and I should not be “forced to stand down” as an Arch Linux developer.

Finally, if you are going to send angry emails to me, at least attempt to make them well enough worded that they can join my “angry email hall of fame”. The latest batch were surprisingly uncreative… In fact, the two emails claiming I would be responsible for the authors failing a course due to them spending time fixing their system instead of doing work were just stupid. Why would you update right before a major assignment is due and why would you send me an email if you are running late? Also, the style of the emails makes me think this was one person sending from two different accounts, so they seem to have plenty of spare time… I did enjoy a comment in the bug tracker that said the glibc maintainer was going postal.