Chris Adams <cmadams(a)hiwaay.net> writes:
Once upon a time, Chip Turner <cturner(a)redhat.com> said:
> Ville Skyttä <ville.skytta(a)iki.fi> writes:
> > The modules come from a vendor -> they should go into vendor install
> > dirs. Site install dirs are for local site installs so that admins can
> > override system installed stuff a la "perl -MCPAN -e install Foo-Bar"
> > and traditional tarball install. (Moving site_perl in /usr/local/...
> > would make this clearer FHS-wise.)
>
> I like that idea. A lot. I'd not thought about it til now, but that
> makes a tremendous amount of sense. It would also address the manpage
> issue, I think. It would break backwards compatibility, though, with
> older RPMs (unless we still looked in the /usr/lib/.../site_perl/
> dirs, but I'm inclined not to).
Hmm, you might as well change "vendor_perl" to "rpm_perl" then. I
don't
want RPM touching /usr/local (that's for the few odds and ends I install
manually and local or per-system scripts), but I install perl modules
from RPMs all the time. "vendor" to me means Red Hat or Fedora, so I
wouldn't make my perl module RPMs install into the "vendor" directory.
Well, perl itself calls it vendor_perl. Various things like 'perl
-V:vendorlib' etc make me hesitant to diverge from upstream naming.
vendor_perl is where Fedora's perl modules end up landing; site_perl
is where your site's perl modules. RPM doesn't really have anything
to do with it. There's no law against rpm managing files living in
/usr/local, but that's one of the few places that is even viable for
things like man pages from third party apps that might conflict with
the ones living in /usr.
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.