Arch Linux

typo: but /usr/lib/perl5/site_perl/5.8.8 contains a buggy 'current' symlink to itself.

imho the dir should be there before, this means git should have perl as depend that it installs first, i'll look into it, but i guess this is a package bug and not a perl one

git 1.5.3.4-1 depends on perl-error, which depends of course on perl.
So I assume this task can be closed now?

sorry I overlooked that this is blocked by FS 7587.

IMO, the perl scriplet has a problem. Here is what happens on a fresh install :

( 8/92) Installation perl [############################] 100%
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.0': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.1': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.2': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.3': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.4': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.5': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.6': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.7': No such file or directory
ln: creating symbolic link `usr/lib/perl5/site_perl/5.8.8': No such file or directory

Thats because the usr/lib/perl5/site_perl dir doesn't exist initially.
After that, if I install the git package, which contains this file :
git /usr/lib/perl5/site_perl/5.8.8/Git.pm

It'll create a /usr/lib/perl5/site_perl/5.8.8 directory, instead of the 5.8.8 symlink to current/
that was supposed to be created by perl post_install..

After that, if I reinstall perl, it'll create the following buggy symlink :
/usr/lib/perl5/site_perl/5.8.8/current -> current

I hope it's clear enough. If it isn't, just do a fresh install of perl in an alternate RootDir (pacman -r foo/ ...), and then git.

ok now i get it, thanks.

I agree that the perl post_install function could be much improved (i'll look more closely into this... i am currently working on a "perl-dev" package for version 5.9.5 that may or may not go to AUR).

(BTW I tried to reproduce the above but I can't install to an alternate root dir : "pacman -r tmp/ -S perl" fails with the msg "perl not found in sync db")...

In any case there is a problem with the packaging of git, since Git.pm should install to site_perl/current ... Is there a bug report for that? Now I just did
grep site_perl/5.8.8 /var/lib/pacman/local/*/files
on my machine (which has a very large number of perl packages installed!) and found that, in addition to git, these packages have a similar problem:
acidrip, net-snmp, perl-email-valid, perl-html-widget, and perl-test-nowarnings.
So perhaps I should open a new task for each one of them?

I can't answer this question, I don't have a clue about packaging in general (and even less about perl packaging in particular).

But I can help you reproduce it. You need to put the sync db in the alternate root dir by running -Sy first.
And then install a minimal environment, so that scriptlets can be run inside the chroot (also, the chroot requires root privilege btw).

1) mkdir -p foo/var/cache/pacman
2) ln -s /var/cache/pacman/pkg foo/var/cache/pacman
3) sudo /usr/bin/pacman -r foo/ -Sy bash filesystem coreutils grep gawk
4) sudo /usr/bin/pacman -r foo/ -S perl

Thanks Xavier, I'll try this. I have now added related tasks for git (FS #8231), net-snmp (#8233) and acidrip (#8235).

Ok, but note that the creation of the buggy symlink isn't really the fault of these packages, but it's rather the fault of perl scriptlet imo.
What's the point of creating all these symlinks if every perl packages install directly to current/ ?

Also, it seems bogus to me that perl scriptlet try to make symlinks inside /usr/lib/perl5/site_perl/ without even creating/owning this directory in the first place.

Xavier, I was unable to reproduce what you described above in my chrooted environment. Fresh install of perl does not produce any warnings, and reinstalling it after installing git does not show any problem with symlinks etc.

However in my normal environment I have indeed noticed that /usr/lib/perl5/5.8.8 was no longer a symlink to current, and that it contained Git.pm and some other modules (notably from net-snmp). I fixed that manually. So my point is that it is not yet clear what caused the replacement of the symlink into a normal dir in the first place!!

Concerning the install script for perl: there was a good reason for all those symlinks. The problem is more with pacman apparently (see http://bugs.archlinux.org/task/7587).

1) I really can't explain why you can't reproduce it if you followed my instructions. Was /usr/lib/perl5/site_perl/ created (and at which point) ? And does it contain the symlinks?
2) That can be explained by  bug 7484 , which is fixed in pacman 3.0.6 / 3.1 (git).
3) My question is : why doesn't perl own the /usr/lib/perl5/site_perl/ directory?

1) Yes, /usr/lib/perl5/site_perl is created when perl is installed. It contains the symlinks as well as the empty subdir i686-linux-thread-multi. They are plainly created by perl's install script (line 13).
2) this is possible, as I have pacman 3.0.6: can you reproduce it again with this version?
3) well, pacman does not care for ownership of directories, only files.

I was using the testing package. It works fine with the core one.
Here are the changes :
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/perl/PKGBUILD.diff?r1=1.48&r2=1.49&cvsroot=Core&only_with_tag=TESTING

options=('!emptydirs') is probably the culprit.

Status on this?
Was reported for 5.8.8-7 too: http://bugs.archlinux.org/task/8306

Try this PKGBUILD:

still valid? I've seen an update in the past few days.

Since git indirectly depends on perl, and emptydirs has been reintroduced in the perl PKGBUILD :
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/perl/PKGBUILD.diff?r1=1.50&r2=1.51&cvsroot=Core

I would say this is fixed.

However, it might still be possible to make the scriptlet safer, maybe by checking the existence of /usr/lib/perl5/site_perl/ and /usr/lib/perl5/site_perl/5.8.x directories, and taking this into consideration.

I believe this is fixed. See the last comments on  FS#8389 .

These last comments don't seem to be related. How did the -9 revision fix the bug?
Several users mentioned the perl package just needed to be rebuilt for fixing  FS#8389 , so this would indicate rather a build (linking lib or whatever) problem than a symlink problem, wouldn't it?

It also seems like there was a lot of confusion about the symlink problem:
When a package installs a file in /usr/lib/perl5/site_perl/5.8.8 , this is NOT supposed to delete the 5.8.8 symlink and replace it by a directory.
This was only a consequence of a pacman bug ( FS#7484 ), which is fixed since pacman 3.0.6 release.
However, once the 5.8.8 symlink is broken, it has to be fixed manually by the user, but that's all.

But, I'm a bit confused about what the current bug report is about. I can only say since emptydirs option was enabled again in perl package, and since the symlink bug in pacman was fixed, a fresh install of Arch, perl and perl modules should work just fine.
What will probably not work fine is an already broken system.

In my last comment, I was also thinking about a possibility to make the scriptlet more robust (for example to prevent the creation of buggy symlinks as stated in the bug report), but I'm not sure, and no one else bothered to comment, so forget it.

I fully agree with Xavier. The idea of making the install script more robust is also good. I had a look at perl 5.8.8-10 in CVS (not yet in testing), which is a first step at implementing the new Perl policy (http://wiki.archlinux.org/index.php/Perl_Policy). There are some problems to fix there, so that would be a nice opportunity to think about a more robust approach to these symlinks and other issues.

The symlinks are not required with the new perl policy and are now removed by the perl.install in perl 5.8.8-10 and 5.10.0-1. This can probably be closed.

Oh indeed, if they are not required anymore, it's great, and this bug is then irrelevant.
The new perl.install apparently worked fine here.

Thanks Kevin, this just made me happy when going through my emails. Yay!

Kevin - see  bug 7587  as well when closing this one. I think that one is valid to close also.