On Fri, 28 Jul 2000, Peter Jones wrote:
> On Fri, 28 Jul 2000, Khimenko Victor wrote:
>
> > On Fri, 28 Jul 2000, Peter Jones wrote:
> >
> > > You've missed the point of /usr/local . FHS says that a vendor can't put
> > > things in /usr/local; not that a sysadmin can't. If a vendor is shipping
> > > perl, /usr/lib/perl5 and /usr/bin/perl is _just fine_. By definition,
> > > that _isn't_ local.
> >
> > You missed the point here. Yes, /usr/lib/perl is just fine. But what
> > about locally compiled modules ? You can download thing from CPAN,
> > compile it and install. It's simple: perl Makefile.PL ; make ; make
> > install ... It'll compile CPAN module and will install it ... where
> > it'll install it ? Currently it'll install it in
> > /usr/lib/perl5/site_perl/i386-linux (arch-dependant files) or in
> > /usr/lib/perl5/site_perl (non-arch-dependant files). Emacs will search
> > for additional packages in /usr/share/emacs/20.7/site-lisp (and
> > /usr/share/emacs/site-lisp) and so on. And sysadmin can not change it
> > easily: you need to recompile perl, emacs or tcl. So instead of SINGLE
> > place where all local stuff is stored (/usr/local) you have LOCAL
> > stuff scattered all over /usr :-( For C libraries problem is solved:
> > you can put .h files in /usr/local/include and libraries in
> > /usr/local/lib an your system compiler can find all local stuff there.
> > For other packages FHS offer no solution :-((
>
> Regardless, the pointing of perl (or any other program) at /usr/local/* is
> _the sysadmin's responsibility_, not the distributor's.
Debian policy say it's other way around ( see
http://www.debian.org/doc/debian-policy/ch3.html#s3.1.2 ) ... I think it's
correct: it's easy to understood that if you have /usr/local/share/emacs
directory that you can put files there. It MUCH harder to notice that
if you'll CREATE directory there and THEN put stuff in there emacs will
spot it.
> There isn't any need for the packager of the distribution to point
> things at /usr/local;
Yeah ? Where to point it then ?
> and even if you _do_ insist (as a packager) to do this, then the (obvious)
> solution is to make sure that perl doesn't complain if its "use lib" path
> doesn't exist, and wait until you're actually building that CPAN module to
> make the directory there.
>
Not all programs have such automagic installation mechanism in place. When
it's enough to put file in there it really looks like overkill to develop
one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:28 EST