What"s the difference between /usr/(lib|share)/(perl|perl5)?

Hi all.

Can someone tell the difference between:

/usr/lib/perl
/usr/lib/perl5
/usr/share/perl
/usr/share/perl5

and the corresponding dir with the /usr/local prefix (or tell a
relevant link)?

I know about @INC, that in my system (debian etch, perl 5.8.8) returns:

/etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8
/usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
/usr/local/lib/site_perl

I noticed that CPAN seems to install modules in
/usr/local/lib/perl/5.8.8

but frankly I can't actually tell the difference between modules
installed in all these various directories (apart from the obvious fact
that /usr/local is used for installing modules not managed by the
package management system).

In particular where am I supposed to put modules used by scripts that
only have to run in my system, and where am I supposed to put
modules in a source perl package (/usr/local/share/perl,
/usr/local/lib/perl, /usr/local/share/perl5, /usr/local/lib/perl5 ?).

Many thanks in advance
Cheers
--
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)

Re: What"s the difference between /usr/(lib|share)/(perl|perl5)?

On 2007-03-03 15:41, Stefano Sabatini wrote:
> Can someone tell the difference between:
>
> /usr/lib/perl
> /usr/lib/perl5
> /usr/share/perl
> /usr/share/perl5
>
> and the corresponding dir with the /usr/local prefix (or tell a
> relevant link)?
>
> I know about @INC, that in my system (debian etch, perl 5.8.8) returns:
>
> /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8
> /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
> /usr/local/lib/site_perl

So you are actually asking about the difference between:

/usr/lib/perl/5.8
/usr/lib/perl5
/usr/share/perl/5.8
/usr/share/perl5

? That's more a Debian/Linux question than a Perl question.

/usr/lib is meant for platform-specific code and (read-only) data. If a module
contains compiled code, it should go there. /usr/share is meant for
platform-independent code and (read-only) data: Pure perl modules should
go there.

Similarily, modules which need perl 5.8.x should go into .../perl/5.8
while modules which work with any perl 5 can go inot .../perl5.

> I noticed that CPAN seems to install modules in
> /usr/local/lib/perl/5.8.8

Yup. Locally installed stuff should go into /usr/local. Since cpan
doesn't install into different places according to debian policy,
everything is installed into the most specific place: .../lib/...
because the module might be platform dependent, and .../perl/5.8.8
because it might not work with any other version.

> In particular where am I supposed to put modules used by scripts that
> only have to run in my system, and where am I supposed to put
> modules in a source perl package (/usr/local/share/perl,
> /usr/local/lib/perl, /usr/local/share/perl5, /usr/local/lib/perl5 ?).

Use Module::Builder or ExtUtils::MakeMaker to install your modules. That
will "do the right thing" if perl was setup sanely by your linux
distribution (as is the case for Debian Etch).

hp

--
_ | Peter J. Holzer | Es ist ganz einfach ihn zu verstehen, wenn
|_|_) | Sysadmin WSR | man nur alle wichtigen Worte im Satz durch
| | | hjp@hjp.at | andere ersetzt.
__/ | http://www.hjp.at/ | -- Nils Ketelsen in danr

Re: What"s the difference between /usr/(lib|share)/(perl|perl5)?

Hi Peter.

On 2007-03-03, Peter J. Holzer wrote:
> On 2007-03-03 15:41, Stefano Sabatini wrote:
>> Can someone tell the difference between:
>>
>> /usr/lib/perl
>> /usr/lib/perl5
>> /usr/share/perl
>> /usr/share/perl5
>>
>> and the corresponding dir with the /usr/local prefix (or tell a
>> relevant link)?
>>
> [CUT]
> So you are actually asking about the difference between:
>
> /usr/lib/perl/5.8
> /usr/lib/perl5
> /usr/share/perl/5.8
> /usr/share/perl5
>
> ? That's more a Debian/Linux question than a Perl question.
>
> /usr/lib is meant for platform-specific code and (read-only) data. If a module
> contains compiled code, it should go there. /usr/share is meant for
> platform-independent code and (read-only) data: Pure perl modules should
> go there.
>
> Similarily, modules which need perl 5.8.x should go into .../perl/5.8
> while modules which work with any perl 5 can go inot .../perl5.

OK, much clearer now, thanks!

Mmh... so perl5 should be used for modules that should work with
*every* version of perl 5.x.y, while the various
/(share|lib)/perl/ dirs should contain modules
specific for a specific version... thus in order to avoid errors one
should always choose the version specific directory, that is what cpan
seems to automatically do.

Is it right?

> [CUT]
>> In particular where am I supposed to put modules used by scripts that
>> only have to run in my system, and where am I supposed to put
>> modules in a source perl package (/usr/local/share/perl,
>> /usr/local/lib/perl, /usr/local/share/perl5, /usr/local/lib/perl5 ?).
>
> Use Module::Builder or ExtUtils::MakeMaker to install your modules. That
> will "do the right thing" if perl was setup sanely by your linux
> distribution (as is the case for Debian Etch).
>

Yes, it's a wise advice, but I was trying to build a package with a
perl script and a specific perl module (not meant to be used
indipendently from the script), and I wanted to avoid to mix autoconf
and MakeMaker, so the simple solution seemed to detect the
installation dirs without to rely on not autoconf/make tools.

Cheers
--
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)

Re: What"s the difference between /usr/(lib|share)/(perl|perl5)?

On 2007-03-03 21:58, Stefano Sabatini wrote:
> Hi Peter.
>
> On 2007-03-03, Peter J. Holzer wrote:
>> On 2007-03-03 15:41, Stefano Sabatini wrote:
>>>
>> So you are actually asking about the difference between:
>>
>> /usr/lib/perl/5.8
>> /usr/lib/perl5
>> /usr/share/perl/5.8
>> /usr/share/perl5
>>
>> ? That's more a Debian/Linux question than a Perl question.
>>
>> /usr/lib is meant for platform-specific code and (read-only) data. If a module
>> contains compiled code, it should go there. /usr/share is meant for
>> platform-independent code and (read-only) data: Pure perl modules should
>> go there.
>>
>> Similarily, modules which need perl 5.8.x should go into .../perl/5.8
>> while modules which work with any perl 5 can go inot .../perl5.
>
> OK, much clearer now, thanks!
>
> Mmh... so perl5 should be used for modules that should work with
> *every* version of perl 5.x.y, while the various
>/(share|lib)/perl/ dirs should contain modules
> specific for a specific version... thus in order to avoid errors one
> should always choose the version specific directory, that is what cpan
> seems to automatically do.
>
> Is it right?

Yep, except for the "should always". What you should do depends on what
you are trying to achieve. cpan installs a module on a single machine
for a specific version of perl - so it chooses the most specific
directory to avoid disturbing other perl versions which might be
installed on the same machine. If you are building a package which
should be installed on many machines, maybe with different linux
distributions and perl versions, you need to install into a directory
which is in @INC on all of these machines (for example, when I created
RPMs for qpmstpd I chose /usr/lib/perl5/site_perl, because that is in
@INC on all Redhat and Fedora versions since at least Redhat 7.3 (the
oldest version I am attempting to support).


>>> In particular where am I supposed to put modules used by scripts that
>>> only have to run in my system, and where am I supposed to put
>>> modules in a source perl package (/usr/local/share/perl,
>>> /usr/local/lib/perl, /usr/local/share/perl5, /usr/local/lib/perl5 ?).
>>
>> Use Module::Builder or ExtUtils::MakeMaker to install your modules. That
>> will "do the right thing" if perl was setup sanely by your linux
>> distribution (as is the case for Debian Etch).
>>
>
> Yes, it's a wise advice, but I was trying to build a package with a
> perl script and a specific perl module (not meant to be used
> indipendently from the script), and I wanted to avoid to mix autoconf
> and MakeMaker, so the simple solution seemed to detect the
> installation dirs without to rely on not autoconf/make tools.

I don't see what you need autoconf for, but then I don't know your
script.

hp


--
_ | Peter J. Holzer | > it's the auto-tools that are somewhat
|_|_) | Schriftführer LUGA | > harder to grasp.
| | | hjp@luga.at | I think they try to avoid being grasped so
__/ | http://www.luga.at/ | people don't choke them to death. --mattdm