[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: lintian's view of the world of perl

On Tue, Jan 14, 2003 at 04:06:56PM +0100, Josip Rodin wrote:
>On Tue, Jan 14, 2003 at 01:38:29PM +0000, Colin Watson wrote:
>> For an obvious counterexample to the ".pm files in /usr/lib are wrong"
>> position, look at /usr/lib/perl/5.8.0/Config.pm. I'd also find it hard
>> to claim with a straight face that it would be a good idea for MakeMaker
>> to install DynaLoader.pm in an architecture-independent position.
>Hmm, I didn't see the quote from bod, Ardo wrote above the quote so I didn't
>even bother looking at it. Sorry.

*Every* XS module will have at least one .pm which gets installed under
/usr/lib/perl5, even if that file only subclasses DynaLoader then
bootstraps the compiled code.

As far as I'm concerned, the correct location for such .pm files is
under /usr/lib along with the .so .

>So, all right, there are valid cases where pm is fine in /usr/lib, but that
>only makes an error a warning in Lintian terminology, which it is, because
>I suspected there might be exceptions. I still have over 3 MB of ordinary
>.pm files and another 10 MB of normal textual files in my system's
>/usr/lib/perl5 that don't appear to have anything particularly

Packages with arch "all" should *never* be installing files under
/usr/lib/perl5.  lintian can certainly check that.

Binary packages are a different matter.

>1.2 MB of those are .pod and AFAIK that's documentation so I guess it can be
>added to the .p(m|l) regexp. I also see an insane number of image files
>below Tk/, which makes me think people are used to stuffing whatever the
>hell they want in the /usr/lib/perl5 hierarchy.

Well, some binary modules do provide more than just a single .pm to
bootstrap the code--if you look at libapt-pkg-perl for example there are
half a dozen perl modules, none of which are really useful without the
AptPkg.so binary.  There's even a .pod file in there, although that's
only split out from Config.pm to work around for MakeMaker out-clevering

In a nutshell, MakeMaker chooses /usr/share/perl5 or /usr/lib/perl5
(based on pure-perl vs. XS) then installs *everything* under the
selected tree.

This makes a lot of sense in the context of the perl parts of XS modules
not being shareable without the corresponding binary, although means
that in some degenerate cases such as perl-tk you may end up with more
stuff under /usr/lib than is strictly necessary.

It's worth noting also that upstream doesn't even vaguely follow
FHS--everything is under /usr/lib/perl5 by default.


Reply to: