(This may need to be filed against the filesystem or man page component, but it's motivated by Perl's packaging.) When installing 3rd party Perl RPM/CPAN packages, one typically installs them to the site directories so that the files don't conflict with those bundled with the vendor Perl package. This is fine for binaries, but there's no site directory in which to put the man pages. For instance, I need to update MIME::Base64, a package bundled with the vendor Perl, and I can use "cpanflute2 --installdirs=site" to create an RPM with the module placed in /usr/lib/perl5/site_perl. But there's no equivalent site man directory to place the matching man pages, so I get a conflict when attempting to install the resulting package. The location of the directory is probably something that the FHS people need to decide. Perhaps /usr/share/man/site.
Yep, such a dir could be useful indeed. And I agree this is something that upstream (FHS/Perl) should decide/implement. You have submitted this request there already, right? ;) Of course, there are some suboptimal options for working around the conflict now, for example not installing the man pages at all (perldoc Module::Name would still "work"), or installing into a custom dir and tweaking MANPATH (see eg. /usr/share/perl5/man in /etc/man.config).
Filed with FHS here: http://bugs.freestandards.org/show_bug.cgi?id=78 Who decides the layout of Perl's directories? I haven't found an equivalent tracker for Perl to post this to.
Maybe http://dev.perl.org/
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Not for legacy, this is actually a RFE for future FC perl packages, and possibly to some extent future upstream Perl releases. Back on topic: moving the entire site_perl hierarchy to /usr/local would be an easy fix for this, and it'd have other useful properties too.
> Back on topic: moving the entire site_perl hierarchy to /usr/local would be an > easy fix for this, and it'd have other useful properties too. We used to do this for BU Linux, and it worked very well. (I just got tired of patching the perl RPM.)
How large of a change will this need?
The basic specfile change is small -- a few tweaks to the Configure statement. But I'm not sure about the full impact for upgrades, etc.
IMO needs discussion on fedora-perl-devel and elsewhere, anyway too big for FC4 at this point.
And upstream FHS and perl needs to set the standard.
They already have: /usr/local : Local hierarchy Purpose The /usr/local hierarchy is for use by the system administrator when installing software locally. 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.
Matthew: never EVER touch my /usr/local with packages! That's the least GoodThing FHS "establishes" ;-) Back on track, no, not (only) perl. If we would stick to the "subject", placing those man pages into a "%{_mandir}/manp/" would be enough to leverage the files conflict. Yes, I know it's just (another) workaround (with its own pros/cons), but at least it will (quite) work with the default man.config. IAE, this is not "THE" (real) issue. (As always) many workarounds (filed as "bugs" on the same bugtracker we're currently watching) are being filed just because our packaging system doesn't support "this" or "that" feature (and the main reason why some of our fellow developers "fallback" to other packaging systems - like [dq]pkg). IAE - yes, again - as this is not a "generic" boutade (and we're not on mozilla's bugtracker), I'll stop here with an "Happy Easter" ;-) As memento, don't touch /usr/local, it's one of the GoodThings RedHat/Fedora's guidelines stick to. :)
Marius -- exactly right. The point is to make _non-packaged_ Perl modules (those installed locally) go into /usr/local instead of smearing themselves all over /usr/lib/perl5/.
Matthew, the issue raised by Kenneth here it's NOT about "non-packaged" files/modules/etc, but exactly about "how to make addon packages that should override distro files". OK, Kenneth minimized it to the state of a very particular issue, but the generic problem still stands, and kludging this "vendor specific man page directory" (yes, he meant _vendor_) - e.g. using that "%{_mandir}/manp/" trick - won't make the world better. ;-/ For instance, I don't get it who come [non-overriding] "is fine for binaries". Even more, remember what will happen when (main) perl package is updated: your addon package will _still_ override the distro package, given the current @INC's state in Fedora's perl package. Should I also mention that you will not be able to install your package as long Fedora tends to obsolete every separated-core-module-package (iep, they existed long ago, in the era of Chip Turner IIRC), _without_ specifying a version (e.g.: Obsoletes: perl-CPAN <= 1.76_02). So, IMHO a WONTFIX/CANTFIX resolution for this issue would be an easy way out (for now).
Marius -- the issue of 3rd-party RPM packages is a red herring and I agree that that portion should be considered hard to fix. However, the suggestion in comment #5 is still relevant for local and CPAN-installed modules, and there's no reason not to address that just because the _other_ part you're concerned about is difficult.
Matthew, I _absolutely_ agree with Ville. After all, "site_perl" has nothing to do with /usr, /usr/local is the _right_ place. Repeating that Kenneth meant to bake RPM packages, this is what I wanted to emphasize in fact, at least for Kenneth and others that may not know about our oldies but goldies conventions regarding (perl|site|vendor)dirs, which is exactly what you and Ville said after all: sitedir must not include RPM managed files, the same way /usr/local works. ;-) So, what stands out after all this chatter is Ville's proposal to move out sitedir under /usr/local. Ville, have you already submitted a request for this? :)
Well, I think we had been considering *this* to be tracking that request. :) But if it makes it more clear, we can fork this into a new bug....
Comment 17 seconded. By the way, if the move is implemented sometime, things such as bug 151195 need a priority bump (not that it wouldn't be good to have fixed already now, and that report is probably somewhat bitrotten already). And then there's the backwards compatibility issue of what happens to stuff locally installed to the current site hierarchy. Unless I'm missing something, it might not be a bad idea to hold this change until the next point of time where perl no longer loads modules from hierarchies for earlier versions anyway.
assigning to rnorwood
site_perl directories moved to /usr/local in rawhide.
Cool!