On Wed, Apr 30, 2003 at 05:12:03PM -0500, Gunnar Wolf wrote: > Per request of its current maintainer (Cc: of this mail goes to him), I > am working on a NMU of libapache-request-perl because of a new upstream > version. I would like to correct a couple of Lintian warnings in the > process as well. I stumbled across this, however: > > W: libapache-request-perl: package-installs-nonbinary-perl-in-usr-lib-perl5 > usr/lib/perl5/Apache/libapreq.pm > N: > N: Architecture-independent Perl code should be placed in > N: /usr/share/perl5, not /usr/lib/perl5. > N: > W: libapache-request-perl: package-installs-nonbinary-perl-in-usr-lib-perl5 > usr/lib/perl5/Apache/Request.pm > W: libapache-request-perl: package-installs-nonbinary-perl-in-usr-lib-perl5 > usr/lib/perl5/Apache/Cookie.pm > > Now, I started digging a bit into this - Out of 752 files I have in my > /usr/lib/perl5, 121 are plain Perl modules - Quite a sizable proportion! > Is this policy requirement enforceable at all? Could lintian be raising > a false positive warning?
I think this lintian warning is rubbish, as does the perl maintainer: http://lists.debian.org/debian-perl-0301/msg00000.html I suggest adding a lintian override. The modules in question are closely tied to their XS implementations; if they ever got out of sync (i.e. if somebody was seriously sharing /usr/share between machines, rather than it just being a theoretical exercise) the consequences would be unpleasant. -- Colin Watson [EMAIL PROTECTED]
