Messages in this thread | | | Date | Sat, 29 Jul 2000 01:08:10 +0400 (MSD) | From | Khimenko Victor <> | Subject | Re: RLIM_INFINITY inconsistency between archs |
| |
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/
| |