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
>architecture-dependent.
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
itself.
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.
--bod
Reply to: