The upgrade from Perl 5.10 to 5.12.1 in Arch have caused a lot of headache. I had to manually rebuild almost 600 modules and a lot of regular users are frustrated due to the suddenly changed perl-bin-path, from the sane /usr/bin/perlbin path to hiding them in /usr/lib. What the fuck…

I’ve searched, asked and questioned this decision for a couple of months now, to no avail. The path problem isn’t hard to fix, though.

First, use pacman to see where it actually installed things:

$ pacman -Ql colorcoke-git|grep bin
colorcoke-git /usr/lib/perl5/vendor_perl/bin/
colorcoke-git /usr/lib/perl5/vendor_perl/bin/colorcoke

Right. Add that (and the other missing dirs as well) to your $PATH in .bashrc or similar.


Use hash -r (bash) or rehash (zsh), and the PATH will be rehashed for executables.

$ which colorcoke


I just talked to Allan McRae on this issue. The reason why Perl executables are installed in /usr/lib/… is because subdirectories in /usr/bin are not allowed by the Filesystem Hierarchy Standard.

The script that’s supposed to update the PATH only works if the directories does exist. The first time a user will install a package containing Perl executeables, those directories will be created, but the PATH wont be updated until the next time that file is sourced (probably the next time the user logs in).

I suggested to skip those checks and just add the directories to the PATH anyway, but apparently that will create other problems.

Therefore I submitted a bug rapport on the matter, and the solution is pretty simple:

# Set path to perl scripts.
# Remove the perlbin dirs in the next release.

# Create directories and and them to the PATH.

mkdir -p /usr/lib/perl5/{site,vendor,core}_perl/bin &&

export PATH

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

Hopefully, this will be solved pretty fast.