Re: Bug#587991: perl-policy: /etc/perl missing from Module Path

[Dominic Hargreaves <dom@earth.li>]

On Mon, Dec 26, 2011 at 10:05:53AM -0800, Russ Allbery wrote:
> Hello, Perl folks (particularly perl package maintainers),
> 
> There is a long-standing bug against Policy to document that /etc/perl is
> added to the module search path, and indeed that is the behavior of Perl
> currently.  However, in discussing that change, Bill observed:
> 
> Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> 
> > A clarification would be welcome:
> 
> > The only conffile in /etc/perl is /etc/perl/Net/libnet.cfg from
> > perl-modules.  However this file does not look like a perl module.  Now
> > I realize that the proposed policy does not mandate all file in
> > /etc/perl/ to be perl module.
> 
> and indeed when I checked further this facility doesn't appear to be used
> in Debian.  On my system, the only files in /etc/perl are
> /etc/perl/Net/libnet.cfg and /etc/perl/XML/SAX/ParserDetails.ini.  The
> latter is not even Perl.  The former is valid Perl code, but it's not
> being loaded as a Perl module; the path to that file is hard-coded in
> Net::Config and Net::Config doesn't care if it's on the search path.
> 
> Also, in thinking about this, I'm not sure I understand how this facility
> would be used.  Is the intention to allow people to put modules into
> /etc/perl to shadow modules later in the search path?  Under what
> circumstances would one want to do that, rather than using
> /usr/local/{lib,share}/perl/<version> or /usr/{lib,share}/perl5?  I have a
> hard time seeing a full-blown reimplementation of a Perl module as a
> configuration file.

I don't think that this is necessarily the intention, although its
current position in the search path does allow for this.

> I also did a search on packages.debian.org, and as near as I can determine
> there are no packages in Debian sid that install files under /etc/perl
> other than perl-modules (for libnet.cfg), which as mentioned doesn't use
> this capability.  That doesn't catch packages that create files via
> maintainer scripts, of course, which I assume is where the XML::SAX file
> comes from, but it makes me doubt that this capability is needed.

There are a couple of other things which use /etc/perl, from only a
brief look at the perl debian/changelog (/etc/perl/CPAN and
/etc/perl/CPANPLUS). Those files are created by a local administrator
(using the tools shipped).

> I'm not necessarily advocating removing /etc/perl from the module search
> path, since there are backward-compatibility concerns if local site
> administrators put files there, but it makes me wonder if we really should
> be documenting this in the Perl Policy, since that implies it's a facility
> that people should consider using.

Without carrying out an exhaustive survey, the CPAN and CPANPLUS
examples suggest to me that /etc/perl should stay, and given that they
seems like valid use cases, I don't see why it shouldn't be documented.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)