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 <[email protected]> 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) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
