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

