[pacman-dev] difficult symlink "puzzle"
Hi! I ran into a difficult problem: What about symlink directories, if an other package wants to pull some new files to them? Let me explain with an example: See packages git (it contains: /usr/lib/perl5/site_perl/5.8.8/Git.pm). However, /usr/lib/perl5/site_perl/5.8.8/ is a symlink to /usr/lib/perl5/site_perl/current/. What should the package manager do here? The current situation: git package simply overwrites /usr/lib/perl5/site_perl/5.8.8/ symlink with a regular directory, so the dir 5.8.8 contains only git.pm now :-( If we install git first then perl's install script cannot do anything useful with the existing 5.8.8 dir: result is the same :-( The problem main problem, that currently I cannot solve this problem: if pacman treated the 5.8.8 symlink as an existing dir (in the first example), then Git.pm would be copied to current, which easily can run out of pacman's control (if the 5.8.8 symlink will be deleted later with a forced -Rd perl). It's hard to find a good solution imho, pacman should follow dir symlink during package install, and something should be recorded into db (to FILES: 5.8.8/file->current/file), but the precise handling of this would cause big overhead, and is not easy... Bye, ngaba
Is it very important to worry about -Rd ? Using it shouldn't be recommend anyway. I think it's more important to first control the behavior of normal operations is correct. About the current behavior of pacman overwriting symlink, this was caused to the upgrade of libarchive, and this isn't wanted. We are currently trying to reproduce the same behavior (not overwriting symlinks) : http://bugs.archlinux.org/task/7484
Is it very important to worry about -Rd ? No, this is independent from dependencies, git needn't depend on perl :-( Your solution is dangerous, I don't like files on my HDD out of pacman's control. As a hotfix: file conflict error would be best imho. Bye, ngaba
2007/6/29, Nagy Gabor
Is it very important to worry about -Rd ? No, this is independent from dependencies, git needn't depend on perl :-( Your solution is dangerous, I don't like files on my HDD out of pacman's control.
I didn't say it was ideal, but just that I think it should work that way. If packages that put files in /usr/lib/perl5/* depends on perl (directly or indirectly, like git), then you can't remove perl without removing these packages as well. So you do pacman -Rc perl, which should remove everything in the order (with perl last), so that shouldn't cause any problems. Anyway, that's maybe not ideal, but pacman has always worked fine that way (not overwriting dir symlinks), while the current behavior of deleting symlinks break everything.
As a hotfix: file conflict error would be best imho.
hm, I'm not sure what you mean here :) Just fail if there is a symlink on filesystem instead of a directory ? I'm not sure people with an /opt symlink will be more happy with this behavior. Same for all these perl packages.
Greetings from Tacoma, WA, USA, only 2,668 cars stolen last year, Xavier! On Friday, June 29, in the 2007th year of our Lord, you wrote:
(with perl last), so that shouldn't cause any problems.
Anyway, that's maybe not ideal, but pacman has always worked fine that way (not overwriting dir symlinks), while the current behavior of deleting symlinks break everything.
As a hotfix: file conflict error would be best imho.
hm, I'm not sure what you mean here :) Just fail if there is a symlink on filesystem instead of a directory ? I'm not sure people with an /opt symlink will be more happy with this behavior. Same for all these perl packages.
Just popping in for a 2 second clarification. ;) Most perl modules in arch are current installed into /usr/lib/perl5/site_perl (arch dependendent modules) and /usr/lib/perl5/site_perl/current (arch independent modules). The reason for the symlink farm is because the archlinux _perl_ package is compiled to only look in /usr/lib/perl5/x.x.x/ for modules. Packages which install modules into /usr/lib/perl5/x.x.x are misbehaving, or at least misbehaving to archlinux convention. Pacman should not replace /usr/lib/perl5/x.x.x/ with a directory, but any package installing modules into that path are broken anyway. ;) I've been working on http://wiki.archlinux.org/index.php/Perl_Policy which hopefully will provide some standarization. Not a lot of interest so far though. I think most people interested in perl+archlinux use my perlcpan repository anyway. -- Take it easy, Charles FSF Apologist, WikiNut, Concrete Analyst, etc. JABBER: cmauch@gmail.com GIZMO: charlesmauch AIM: cmauch5 Please send personal email to cmauch@gmail.com :: I am immune to all forms of temptation and seduction. Except for Cute.
participants (3)
-
Charles Mauch
-
Nagy Gabor
-
Xavier