Chris Adams <cmadams@xxxxxxxxxx> writes:
> Once upon a time, Chip Turner <cturner@xxxxxxxxxx> said:
>> Ville Skyttà <ville.skytta@xxxxxx> 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@xxxxxxxxxx
Red Hat, Inc.
