Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#7530 - negligent symlink creating post_install script of perl5

Attached to Project: Arch Linux
Opened by Nagy Gabor (combo) - Friday, 29 June 2007, 09:12 GMT
Last edited by Aaron Griffin (phrakture) - Monday, 07 January 2008, 23:56 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Aaron Griffin (phrakture)
Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.05 Duke
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

perl version: 5.8.8-5
I have /usr/lib/perl5/site_perl/5.8.8 directory before install perl, because git package creates /usr/lib/perl5/site_perl/5.8.8/Git.pm (<- is this OK?).
So when I install perl, /usr/lib/perl5/site_perl/5.8.8 remains dir, and doesn't point to /usr/lib/perl5/site_perl/current (this is a very difficult question, it will be reported to pacman dev), but /usr/lib/perl5/site_perl/5.8.8 contains a buggy symlink to itself.
This task depends upon

Closed by  Aaron Griffin (phrakture)
Monday, 07 January 2008, 23:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  The perl package no longer requires these symlinks
Comment by Nagy Gabor (combo) - Friday, 29 June 2007, 09:14 GMT
typo: but /usr/lib/perl5/site_perl/5.8.8 contains a buggy 'current' symlink to itself.
Comment by Tobias Powalowski (tpowa) - Sunday, 22 July 2007, 06:37 GMT
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
Comment by Francois Charette (Firmicus) - Friday, 05 October 2007, 17:58 GMT
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?
Comment by Francois Charette (Firmicus) - Friday, 05 October 2007, 18:00 GMT
sorry I overlooked that this is blocked by FS 7587.
Comment by Xavier (shining) - Friday, 05 October 2007, 18:21 GMT
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.
Comment by Francois Charette (Firmicus) - Friday, 05 October 2007, 19:06 GMT
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?
Comment by Xavier (shining) - Friday, 05 October 2007, 19:33 GMT
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
Comment by Francois Charette (Firmicus) - Saturday, 06 October 2007, 18:17 GMT
Thanks Xavier, I'll try this. I have now added related tasks for git (FS #8231), net-snmp (#8233) and acidrip (#8235).
Comment by Xavier (shining) - Saturday, 06 October 2007, 18:31 GMT
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.
Comment by Francois Charette (Firmicus) - Saturday, 06 October 2007, 19:11 GMT
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).
Comment by Xavier (shining) - Saturday, 06 October 2007, 19:39 GMT
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?
Comment by Francois Charette (Firmicus) - Saturday, 06 October 2007, 20:12 GMT
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.
Comment by Xavier (shining) - Saturday, 06 October 2007, 22:55 GMT
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.
Comment by Roman Kyrylych (Romashka) - Monday, 15 October 2007, 08:55 GMT
Status on this?
Was reported for 5.8.8-7 too: http://bugs.archlinux.org/task/8306
Comment by Roman Kyrylych (Romashka) - Monday, 15 October 2007, 10:08 GMT
Try this PKGBUILD:
   PKGBUILD (2.3 KiB)
Comment by Andreas Radke (AndyRTR) - Thursday, 15 November 2007, 19:57 GMT
still valid? I've seen an update in the past few days.
Comment by Xavier (shining) - Thursday, 15 November 2007, 20:48 GMT
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.
Comment by Roman Kyrylych (Romashka) - Wednesday, 05 December 2007, 10:51 GMT
I believe this is fixed. See the last comments on  FS#8389 .
Comment by Xavier (shining) - Wednesday, 05 December 2007, 11:46 GMT
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.
Comment by Francois Charette (Firmicus) - Wednesday, 05 December 2007, 13:40 GMT
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.
Comment by Kevin Piche (kpiche) - Tuesday, 01 January 2008, 21:12 GMT
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.
Comment by Xavier (shining) - Tuesday, 01 January 2008, 22:50 GMT
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.
Comment by Aaron Griffin (phrakture) - Wednesday, 02 January 2008, 16:41 GMT
Thanks Kevin, this just made me happy when going through my emails. Yay!
Comment by Dan McGee (toofishes) - Thursday, 03 January 2008, 06:27 GMT
Kevin - see  bug 7587  as well when closing this one. I think that one is valid to close also.

Loading...