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

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



Niko Tyni <ntyni@debian.org> writes:

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

Yeah, we could do that.  Although as someone who tends to use Perl code as
a configuration language for a lot of my own scripts, because it's so
convenient to be able to load the configuration file with require, I don't
think the problem is as large as that.

Also, some packages really do need Turing-complete configuration languages
because they support configuration callbacks.  For example, the WebLogin
component of WebAuth supports an arbitrary username remapping function
that can be provided by the local administrator and will be applied prior
to the Kerberos authentication inside WebLogin, which is easy to do since
the configuration file is Perl.

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

I admit that I don't much care for this, mostly because I'm not a big fan
of the proliferation of directories in /etc.  I would support that if they
were programs rather than modules, but I kind of like the idea that Perl
module configuration files (ones loaded by the module when one loads the
module with "use") are all together in one place.

It's only a very minor thing, though.

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

I do agree that putting them in @INC is sort of inherently messy, and I
thought about that for a while.  But I also don't think it's likely to
cause harm, assuming that no one does something really dumb like end the
file name with *.pm even when it's not Perl.

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

I'd be okay with that.  I think I have a very minor preference for
allowing it, but I don't particularly care one way or the other.

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



Reply to: