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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
