[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 02:06:32PM +0100, Josip Rodin wrote:
> On Mon, Jan 13, 2003 at 08:24:32PM -0600, Ardo van Rangelrooij wrote:
> > The latest version of lintian checks for .pm files in /usr/lib/perl5 and
> > generates a warning if so.  This is the result of a bug report filed by
> > Adam Heath.  What the heck?  Shouldn't these things first be discussed
> > _properly_ before filing bug reports and changing tools?
> > 
> > I also don't understand why the lintian maintainer took this bug report
> > on face value and implemented this check.  Is that the new way of doing
> > things in Debian?
> The Debian Perl Policy allows both locations, and FHS says
> architecture-independent data should go to /usr/share instead of /usr/lib.
> I don't see anything wrong with any of that, whereas the inconsistent state
> (i.e. both directories having files) on Debian systems does strike me as
> improper.

I agree with bod that files are not necessarily architecture-independent
simply because file(1) says they are, and I think that this lintian
change should be reverted. If nothing else lintian shouldn't be
pronouncing on things which are still controversial.

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.

> I figured that the Perl Policy didn't ban /usr/lib/perl5 because of
> backwards compatibility, however, that's no reason for us to keep such
> compatibility in packages in sid, and Lintian is predominantly used to
> check packages going into sid.

I don't think compatibility is the only reason, although it was
certainly useful at the time when the current Perl policy was

Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: