Bug#587991: perl-policy: /etc/perl missing from Module Path
On Thu, Jan 05, 2012 at 06:15:41PM +0000, Dominic Hargreaves wrote:
> On Thu, Jan 05, 2012 at 09:07:38AM -0800, Russ Allbery wrote:
> > Dominic Hargreaves <dom@earth.li> writes:
> >
> > > 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).
> >
> > Here's what I currently have, which hopefully also addresses Bill's
> > concerns. Does this look correct?
[...]
> This looks spot on to me; thanks for doing this! Niko, does this make
> sense to you too?
Yes, I think it's describing current practice well. Thanks, Russ.
Still, I do have some concerns.
I think Steve had a good point about Policy endorsing the use of
Turing-complete languages for configuration files. However, I doubt the
CPAN module will ever be changed to use another kind of a configuration
file, and even CPANPLUS may be a stretch. We need something like the
current @INC for those, and it's good to have it documented IMO.
I'm OK with the wording about 'Configuration Modules', and I agree
that Debian packages should not ship regular modules in /etc/perl.
Maybe a footnote about recommending other configuration formats over
arbitrary Perl code would alleviate Steve's concern?
As for libnet.cfg and ParserDetails.ini, both of those seem to me more
like minor bugs than something to bless in Policy. They could equally
well (barring transition issues) go in something like /etc/libnet-perl
and /etc/libxml-sax-perl AFAICS [1].
Arguably /etc/perl looks somewhat nicer in a directory listing, but I
don't think that's a good reason to put non-module configuration files
on @INC. Historical reasons and transition issues may be, and I'm not
volunteering to fix the "bugs", but I don't really think we should
explicitly allow it for new packages.
So I'm not very keen on the 'Configuration Files for Modules' part.
I'd prefer to leave it out, or maybe replace it with something like
While a few packages put non-module configuration files in /etc/perl for
historical reasons, this practice is not recommended for new packages.
Thoughts?
[1] it looks like libnet.cfg is only on @INC because its location used
to be derived from the directory where Net/Config.pm resides, and
we already patch XML::SAX so much that moving ParserDetails.ini out
of @INC wouldn't really make much of a difference.
--
Niko Tyni ntyni@debian.org
Reply to: