[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 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.

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.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: