Bug 142837 - Need site-specific man page directory
Need site-specific man page directory
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2004-12-14 11:39 EST by Kenneth Porter
Modified: 2008-03-18 10:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-18 10:09:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kenneth Porter 2004-12-14 11:39:44 EST
(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.
Comment 1 Ville Skyttä 2004-12-14 18:20:15 EST
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).
Comment 2 Kenneth Porter 2004-12-15 10:43:49 EST
Filed with FHS here:


Who decides the layout of Perl's directories? I haven't found an
equivalent tracker for Perl to post this to.
Comment 3 Ville Skyttä 2004-12-15 13:07:19 EST
Maybe http://dev.perl.org/
Comment 4 Matthew Miller 2005-04-26 11:42:44 EDT
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.
Comment 5 Ville Skyttä 2005-04-26 13:59:37 EDT
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.
Comment 6 Matthew Miller 2005-04-26 14:27:34 EDT
> 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.)
Comment 7 Warren Togami 2005-04-26 20:24:28 EDT
How large of a change will this need?
Comment 8 Matthew Miller 2005-04-26 20:40:53 EDT
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.
Comment 9 Ville Skyttä 2005-04-27 02:59:59 EDT
IMO needs discussion on fedora-perl-devel and elsewhere, anyway too big for FC4
at this point.
Comment 10 Warren Togami 2005-05-31 00:52:02 EDT
And upstream FHS and perl needs to set the standard.
Comment 11 Matthew Miller 2005-05-31 08:15:50 EDT
They already have:

  /usr/local : Local hierarchy


   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.
Comment 12 Marius Feraru 2006-04-24 22:01:31 EDT
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. :)
Comment 13 Matthew Miller 2006-04-24 22:15:10 EDT
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
Comment 14 Marius Feraru 2006-04-25 11:47:08 EDT
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).
Comment 15 Matthew Miller 2006-04-25 12:01:12 EDT
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.

Comment 16 Marius Feraru 2006-04-25 12:36:02 EDT
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? :)
Comment 17 Matthew Miller 2006-04-25 12:41:33 EDT
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 18 Ville Skyttä 2006-04-25 14:12:00 EDT
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.
Comment 19 Robin Norwood 2006-10-01 19:30:26 EDT
assigning to rnorwood@redhat.com
Comment 20 Tom "spot" Callaway 2008-03-18 10:09:42 EDT
site_perl directories moved to /usr/local in rawhide.
Comment 21 Matthew Miller 2008-03-18 10:16:02 EDT

Note You need to log in before you can comment on or make changes to this bug.