Description of problem: Last update of perl rpm attempted to write /usr/local/share/perl5 This causes the update to fail with read-only /usr/local (i.e. NFS mounted). Version-Release number of selected component (if applicable): perl-5.12.4-160.fc15.x86_64.rpm perl-libs-5.12.4-160.fc15.x86_64.rpm How reproducible: Always. Steps to Reproduce: 1. Set /usr/local to read-only 2. Attempt to install perl rpm Actual results: rpm install fails. Expected results: rpm should install normally. Additional info: System rpms should not write to /usr/local There appears to be a similar problem in RHEL 6, bug 717565
Output of attempted rpm install: # rpm -Uvh perl-5.12.4-160.fc15.x86_64.rpm perl-libs-5.12.4-160.fc15.x86_64.rpm Preparing... ########################################### [100%] 1:perl-libs ########################################### [ 50%] error: unpacking of archive failed: cpio: lstat failed - Permission denied error: perl-libs-4:5.12.4-160.fc15.x86_64: install failed 2:perl ########################################### [100%] error: unpacking of archive failed on file /usr/local/share/perl5: cpio: chown failed - Read-only file system error: perl-4:5.12.4-160.fc15.x86_64: install failed error: perl-libs-4:5.12.4-159.fc15.x86_64: erase skipped error: perl-4:5.12.4-159.fc15.x86_64: erase skipped
This is not pure perl problem. E.g. `filesystem' package writes into /usr/local/ too. This is more general problem. Perl interpreter searches in different locations for Perl modules. One of the location is /usr/local/{lib*,share}/perl5 where local superuser can install his own modules. (Similar to /usr/local/bin delivered by `filesystem' package.) Current Perl is quiet if the directory does not exists and current Linux caches dentry misses too, so we can disown the directories. But we cannot guarantee this will be true forever. In fact we had some negative responses on Perl performance when searching nonsearchable directories.
(In reply to comment #2) > This is not pure perl problem. E.g. `filesystem' package writes into > /usr/local/ too. This is more general problem. There are 2 views on this issue: a) The problem is the OP's use-case. /usr/local is not supposed to be networked, but to be machine local directory and not supposed to be read-only. b) The problem is in rpm. rpm should not fail if the directories it tries to install already exist.
In my opinion it makes sense to have a shared /usr/local. It is also very convenient and fairly common. Although I do see that the filesystem package writes there as well, so maybe we should mount it somewhere else. All that the perl package is trying to achieve is to make sure that /usr/local/share/perl5 exists and has the correct permissions, correct? What if this was moved out of the cpio and a bit of shell script was instead used to create the directory. Perhaps then the rpm could give a warning if /usr/local is read-only instead of failing outright?
Directories under /usr/local will be disowned by perl.
(In reply to comment #5) > Directories under /usr/local will be disowned by perl. Veto - This would be a mistake. (In reply to comment #4) > In my opinion it makes sense to have a shared /usr/local. Rest assured, it doesn't. > It is also very > convenient and fairly common. It is only common for folks who are not familiar with the FHS and not familiar with Unix history. The original purpose of /usr/local was to override /usr in search paths on commercial systems where /usr was considered read only. This also is the reason why GNU packages typically install to /usr/local as default, because they presume usrs who install GNU SW, intend to replace vendor SW components with GNU components, without physically destroying the vendor SW. If you want to share packages between machines, /srv is what you are looking for.
You said it yourself, /usr/local is where users can override system packages. Hence, system packages should not write to /usr/local. Let's consider some not so hypothetical questions. First, assume that you have an entire computer lab or rack of machines that are running a commercial non-gnu operating system (of course we would all try and avoid that but it happens). Now say that you want to install a number of gnu packages on each of these machines to override the system packages. Do you spend your entire weekend installing the packages in /usr/local on each machine individually? or do you NFS mount /usr/local and install the packages once? or do you simply abandon /usr/local and put them somewhere else? Next, assume that the vendor of your non-gnu operating system begins releasing packages that write to /usr/local. How would you feel about that? Now, consider that we are running linux. What's the difference? Assume that we have concluded that /usr/local is for stand-alone systems only and that shared/distributed installs should go somewhere else instead. What happens when this location becomes popular? Won't you also need to put your perl search paths there too?
Finally, here is a quote from the Filesystem Hierarchy Standard http://www.pathname.com/fhs/pub/fhs-2.3.html about /usr/local: "It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr" Note the word "shareable." Here is a quote about /srv: "This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed." I believe the standard speaks for itself.
Created attachment 529865 [details] Auto-create site directories perl-5.14.2-196.fc17 does not own the directories. It just prints notice on installation. Iain does not like the notice. This patch tries to create and remove the directories if possible. Thus users with read-only /usr/local gets the message. However the patch is obtrusive (from my point of view) and I'm not sure it works in all cases. Feel free to test it or propose better code implementing this automatism. I'm not confident to push this patch into repositories. Personally I like current always-notice without touching file system because it's simple and give advice in all cases.
Iain's a lot happier about the notice now that he'll (hopefully) never see it.
And Ralf's finds Petr's changes to be absurd.
It does seem like perl-CPAN should try to create /usr/local/ directories as needed (not in the package, but upon execution of CPAN) instead of this hackery.
Of course perl-CPAN should do it. Question is what about users installing packages manually? Even without cpan utilities? I thought some notice at perl-libs installation could be great. However nobody seems to like it. Removing all %post* code from spec file is the easiest solution. Is everybody satisfied with silent perl-libs?
I don't think that is a case for concern. I think if users installing from CPAN aren't having problems, and we know that users installing custom RPM perl packages they've made that install into /usr/local will not have problems (RPM will make the necessary directories), then we're only worried about manual unpacking of tarballs or weird relocatable RPM issues (which we already don't support for a number of reasons). I think it is perfectly acceptable for the perl package to simply not own dirs in /usr/local and not print out anything about it. Now, if there is an issue where perl is trying to index/search pathing below /usr/local which does not exist and perl is having a problem as a result, that seems like a separate bug that should be addressed in perl itself.
The message will be removed in perl-5.14.2-198.fc17.
perl-5.14.2-189.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-5.14.2-189.fc16
Package perl-5.14.2-189.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-5.14.2-189.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15276 then log in and leave karma (feedback).
Package perl-5.14.2-190.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-5.14.2-190.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15276 then log in and leave karma (feedback).
perl-5.12.4-163.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-5.12.4-163.fc15
F14 not affected.
Thanks all! I think this is the appropriate solution.
perl-5.14.2-190.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
perl-5.12.4-163.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.