When installing perl with a prefix in AFS, the Configure script attempts to be too clever. Since most people are not familiar with AFS I will give a little background. AFS is a "global filesystem" in that anyone with AFS installed should be able to look in /afs and see basically the same filesystem. (modulo permissions and setup issues.) Immidiately under the /afs/ directory are directories corresponding to cells (different administrative domains, which generally correspond with domain names). So, for example, CMU owns /afs/andrew.cmu.edu, MIT owns /afs/athena.mit.edu, and I own /afs/mrph.org/. Each of these are traditionally mountpoints for the root.cell volume belonging to the cell of the same name. Volumes are cheap and convenient, and do not require much effort to set up, so typically every user will have a volume for their home directory, and every project that requires AFS space will have it's own volume. On Andrew they create several volumes for every of every software package. (One for the source, and one for the binaries on every supported platform.) OpenAFS (the most common AFS implementation) supports replication of read-only volumes. The way this works is you'll have a rw volume on one fileserver and add replication sites at other fileservers which will server read-only versions of that volume. To update a volume you would modify the rw volume and use vos release to send the update to the ro copies. Normal mountpoints will access an ro copy. This keeps load off the rw server (unless there is also an ro copy on the rw server) and avoids intermediate changes from affecting users. (So the admin can mess around all he likes in the rw version and only run vos release when it is in a good state.) root.cell is usually highly replicated because you really want to avoid the whole cell going down if a server or two fail, and you want to distribute the load. It also typically contains nothing more than directories and mountpoints for other volumes, and you would almost certainly not be installing perl to it. :) Since a normal mountpoint will hit the ro volumes, as sysadmin would need a way to modify the rw one in order to release a new version. This is done by creating a rw mountpoint for that volume somewhere. Typically for /afs/foo.bar the rw mountpoint would be /afs/.foo.bar/. So, perl is trying to be clever and changing the default installprefix when it detects that prefix is in AFS, but the way it is clever is only useful if you are installing to root.cell. In other cases, it generally does no harm, since mounting the rw volume at /afs/.foo.bar/ is very prevalent, and it will usually contain the same data as the ro volume, including the mountpoints that are under it. The problem appears when you mix that with portage. I have my prefix set to /afs/mrph.org/sys/gentoo/amd64_linux26, so portage is trying to find /var/tmp/portage/dev-lang/perl-5.12.1-r1/image/afs/mrph.org/sys/gentoo/amd64_linux26//usr/bin/perl, but of course perl put the file in /var/tmp/port age/dev-lang/perl-5.12.1-r1/image/afs/.mrph.org/... I initially worked around the problem by patching the Configure script, but it's cleaner to just define installprefix along with prefix when calling Configure. (Alternately, defining afs=false would have the same effect.) Tested with 5.8.8-r8, 5.10.1, 5.12.2-r1. Anyways, here is a trivial patch: diff -u portage/dev-lang/perl/perl-5.12.1-r1.ebuild ../aij-overlay/dev-lang/perl/perl-5.12.1-r1.ebuild --- portage/dev-lang/perl/perl-5.12.1-r1.ebuild 2010-07-28 04:31:59.000000000 -0400 +++ ../aij-overlay/dev-lang/perl/perl-5.12.1-r1.ebuild 2010-08-31 17:29:40.000000000 -0400 @@ -276,6 +276,7 @@ -Dcc="$(tc-getCC)" \ -Doptimize="${CFLAGS}" \ -Dprefix="${EPREFIX}"'/usr' \ + -Dinstallprefix="${EPREFIX}"'/usr' \ -Dsiteprefix="${EPREFIX}"'/usr' \ -Dvendorprefix="${EPREFIX}"'/usr' \ -Dscriptdir="${EPREFIX}"'/usr/bin' \
thanks, applied your patch
