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

[Russ Allbery]

Niko Tyni  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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Guy Hulbert]

On Fri, 2012-06-01 at 10:07 +0200, Niko Tyni wrote:
> 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].

Yech.

-- 
--gh





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Niko Tyni]

On Thu, Jan 05, 2012 at 06:15:41PM +, Dominic Hargreaves wrote:
> On Thu, Jan 05, 2012 at 09:07:38AM -0800, Russ Allbery wrote:
> > Dominic Hargreaves  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   nt...@debian.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Dominic Hargreaves]

On Thu, Jan 05, 2012 at 09:07:38AM -0800, Russ Allbery wrote:
> Dominic Hargreaves  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?
> 
> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index 626c514..0ef56f0 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -128,17 +128,27 @@
>
>   Module Path
>   
> -   Perl searches three different locations for modules, referred
> -   to in this document as core in which modules
> -   distributed with Perl are installed, vendor for
> -   packaged modules and site for modules installed by
> -   the local administrator.
> +   Perl searches four different locations for modules, referred to
> +   in this document as config for system configuration
> +   modules, core in which modules distributed with Perl
> +   are installed, vendor for packaged modules,
> +   and site for modules installed by the local
> +   administrator.
>   
>   
> The module search path (@INC) in the Debian packages
> has been ordered to include these locations in the following
> order:
> 
> + config
> + 
> +   
> + Configuration modules (see ).
> + 
> +/etc/perl
> + 
> +   
> + 
>   site (current)
>   
> 
> @@ -395,6 +405,43 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
> 
>   
>
> +
> +  
> + Configuration Files for Modules
> + 
> +   Debian Perl module packages that include configuration files are
> +   allowed (but not required) to put those configuration files
> +   under /etc/perl.  If this path is used for
> +   configuration files, the configuration file must be installed
> +   into a directory under /etc/perl named after the
> +   module, with :: changed to / following the
> +   normal Perl rules for transforming Perl module names into paths.
> + 
> + 
> +   For example, a configuration file for the XML::SAX module would
> +   be installed in the directory /etc/perl/XML/SAX,
> +   and a configuration file used by multiple Net::* modules would
> +   be installed in the directory /etc/perl/Net.
> + 
> +  
> +
> +  
> + Configuration Modules
> + 
> +   Some Perl packages load system-wide configuration from a
> +   dedicated Perl module whose purpose is solely to contain
> +   configuration settings.  The module often contains only variable
> +   settings.  Such modules should be treated as configuration files
> +   and installed under /etc/perl.
> + 
> + 
> +   Debian packages must not install regular modules in this path.
> +   It is reserved for configuration modules that follow the
> +   semantics of configuration files as defined by Debian Policy, or
> +   for configuration files for Perl modules as described
> +   in .
> + 
> +  
>  
>  
>  

This looks spot on to me; thanks for doing this! Niko, does this make
sense to you too?

Cheers,
Dominic.

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



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

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

diff --git a/perl-policy.sgml b/perl-policy.sgml
index 626c514..0ef56f0 100644
--- a/perl-policy.sgml
+++ b/perl-policy.sgml
@@ -128,17 +128,27 @@
   
Module Path

- Perl searches three different locations for modules, referred
- to in this document as core in which modules
- distributed with Perl are installed, vendor for
- packaged modules and site for modules installed by
- the local administrator.
+ Perl searches four different locations for modules, referred to
+ in this document as config for system configuration
+ modules, core in which modules distributed with Perl
+ are installed, vendor for packaged modules,
+ and site for modules installed by the local
+ administrator.


  The module search path (@INC) in the Debian packages
  has been ordered to include these locations in the following
  order:
  
+   config
+   
+ 
+   Configuration modules (see ).
+   
+/etc/perl
+   
+ 
+   
site (current)

  
@@ -395,6 +405,43 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
  

   
+
+  
+   Configuration Files for Modules
+   
+ Debian Perl module packages that include configuration files are
+ allowed (but not required) to put those configuration files
+ under /etc/perl.  If this path is used for
+ configuration files, the configuration file must be installed
+ into a directory under /etc/perl named after the
+ module, with :: changed to / following the
+ normal Perl rules for transforming Perl module names into paths.
+   
+   
+ For example, a configuration file for the XML::SAX module would
+ be installed in the directory /etc/perl/XML/SAX,
+ and a configuration file used by multiple Net::* modules would
+ be installed in the directory /etc/perl/Net.
+   
+  
+
+  
+   Configuration Modules
+   
+ Some Perl packages load system-wide configuration from a
+ dedicated Perl module whose purpose is solely to contain
+ configuration settings.  The module often contains only variable
+ settings.  Such modules should be treated as configuration files
+ and installed under /etc/perl.
+   
+   
+ Debian packages must not install regular modules in this path.
+ It is reserved for configuration modules that follow the
+ semantics of configuration files as defined by Debian Policy, or
+ for configuration files for Perl modules as described
+ in .
+   
+  
 
 
 

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Roberto C . Sánchez]

On Wed, Jan 04, 2012 at 05:06:32PM -0800, Russ Allbery wrote:
> 
> Is it correct to say that packages should not ship modules in /etc/perl,
> or is that too strong?
> 

I agree that packages should not ship modules in /etc/perl.  I cannot
think of a circumstance where a package would have to ship a module in
/etc/perl instead of under /usr/share or /usr/lib.

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

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

[Russ Allbery]

Dominic Hargreaves  writes:
> On Mon, Dec 26, 2011 at 10:05:53AM -0800, Russ Allbery wrote:

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

Ah, thank you.  That was the pointer I needed.  I think I understand what
to say now.

Is it correct to say that packages should not ship modules in /etc/perl,
or is that too strong?

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Dominic Hargreaves]

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  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/ 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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

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  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/ 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 (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[gregor herrmann]

On Fri, 04 Mar 2011 20:15:28 -0600, Jonathan Nieder wrote:

> I see this has been seconded by
> 
>  Niko Tyni  (message #25)
> 
> and I imagine that Russ might be willing to second this, but that
> still leaves us one DD short[1].  Seconds?  Objections?
> Clarifications?

> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index b9f3277..b41342d 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -128,17 +128,27 @@
>
>   Module Path
>   
> -   Perl searches three different locations for modules, referred
> -   to in this document as core in which modules
> -   distributed with Perl are installed, vendor for
> -   packaged modules and site for modules installed by
> -   the local administrator.
> +   Perl searches four different locations for modules, referred to
> +   in this document as etc for system configuration
> +   modules, core in which modules distributed with Perl
> +   are installed, vendor for packaged modules,
> +   and site for modules installed by the local
> +   administrator.
>   
>   
> The module search path (@INC) in the Debian packages
> has been ordered to include these locations in the following
> order:
> 
> + etc
> + 
> +   
> + Configuration modules (see ).
> + 
> +/etc/perl
> + 
> +   
> + 
>   site (current)
>   
> 
> @@ -393,6 +403,17 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
> 
>   
>
> +
> +  
> + Configuration Modules
> + 
> +   Some Perl packages load system-wide configuration from a
> +   dedicated Perl module whose purpose is solely to contain
> +   configuration settings.  The module often contains only variable
> +   settings.  Such modules should be treated as configuration files
> +   and installed under /etc/perl.
> + 
> +  
>  
>  
>  


Seconded.


Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Tracy Chapman: Subcity


signature.asc
Description: Digital signature

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

[Bill Allombert]

On Fri, Mar 04, 2011 at 08:15:28PM -0600, Jonathan Nieder wrote:
> Hi,
> 
> Ansgar Burchardt noticed:
> 
> > perl/5.8.0-7 added /etc/perl to @INC:
> >
> >   * Prepend /etc/perl to @INC to provide a standard location for
> > configuration modules:
> >
> > But this addition has never been documented in the Debian Perl Policy.
> 
> Russ Allbery wrote:
> 
> > Good point.  Here's updated proposed wording.
> 
> I see this has been seconded by
> 
>  Niko Tyni  (message #25)
> 
> and I imagine that Russ might be willing to second this, but that
> still leaves us one DD short[1].  Seconds?  Objections?
> Clarifications?

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.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Fri, Mar 04, 2011 at 08:15:28PM -0600, Jonathan Nieder wrote:

> Ansgar Burchardt noticed:

> > perl/5.8.0-7 added /etc/perl to @INC:

> >   * Prepend /etc/perl to @INC to provide a standard location for
> > configuration modules:

> > But this addition has never been documented in the Debian Perl Policy.

> Russ Allbery wrote:

> > Good point.  Here's updated proposed wording.

> I see this has been seconded by

>  Niko Tyni  (message #25)

> and I imagine that Russ might be willing to second this, but that
> still leaves us one DD short[1].  Seconds?  Objections?
> Clarifications?

> A refreshed patch is attached for reference.

I am uncomfortable with the idea of Policy endorsing the use of
Turing-complete languages for configuration files.  I think software should
use proper configuration libraries instead of this @INC behavior that I was
previously unaware of.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

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

[Jonathan Nieder]

Hi,

Ansgar Burchardt noticed:

> perl/5.8.0-7 added /etc/perl to @INC:
>
>   * Prepend /etc/perl to @INC to provide a standard location for
> configuration modules:
>
> But this addition has never been documented in the Debian Perl Policy.

Russ Allbery wrote:

> Good point.  Here's updated proposed wording.

I see this has been seconded by

 Niko Tyni  (message #25)

and I imagine that Russ might be willing to second this, but that
still leaves us one DD short[1].  Seconds?  Objections?
Clarifications?

A refreshed patch is attached for reference.

Thanks,
Jonathan

[1] http://wiki.debian.org/PolicyChangesProcess#StateE.3AWordingproposed
diff --git a/perl-policy.sgml b/perl-policy.sgml
index b9f3277..b41342d 100644
--- a/perl-policy.sgml
+++ b/perl-policy.sgml
@@ -128,17 +128,27 @@
   
Module Path

- Perl searches three different locations for modules, referred
- to in this document as core in which modules
- distributed with Perl are installed, vendor for
- packaged modules and site for modules installed by
- the local administrator.
+ Perl searches four different locations for modules, referred to
+ in this document as etc for system configuration
+ modules, core in which modules distributed with Perl
+ are installed, vendor for packaged modules,
+ and site for modules installed by the local
+ administrator.


  The module search path (@INC) in the Debian packages
  has been ordered to include these locations in the following
  order:
  
+   etc
+   
+ 
+   Configuration modules (see ).
+   
+/etc/perl
+   
+ 
+   
site (current)

  
@@ -393,6 +403,17 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
  

   
+
+  
+   Configuration Modules
+   
+ Some Perl packages load system-wide configuration from a
+ dedicated Perl module whose purpose is solely to contain
+ configuration settings.  The module often contains only variable
+ settings.  Such modules should be treated as configuration files
+ and installed under /etc/perl.
+   
+  
 
 
 

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

[Niko Tyni]

On Thu, Aug 12, 2010 at 10:45:38AM -0700, Russ Allbery wrote:

> Good point.  Here's updated proposed wording.

> diff --git a/perl-policy.sgml b/perl-policy.sgml
> index 3b76b94..03e5dfb 100644
> --- a/perl-policy.sgml
> +++ b/perl-policy.sgml
> @@ -128,17 +128,27 @@
>
>   Module Path
>   
> -   Perl searches three different locations for modules, referred
> -   to in this document as core in which modules
> -   distributed with Perl are installed, vendor for
> -   packaged modules and site for modules installed by
> -   the local administrator.
> +   Perl searches four different locations for modules, referred to
> +   in this document as etc for system configuration
> +   modules, core in which modules distributed with Perl
> +   are installed, vendor for packaged modules,
> +   and site for modules installed by the local
> +   administrator.
>   
>   
> The module search path (@INC) in the Debian packages
> has been ordered to include these locations in the following
> order:
> 
> + etc
> + 
> +   
> + Configuration modules (see ).
> + 
> +/etc/perl
> + 
> +   
> + 
>   site (current)
>   
> 
> @@ -393,6 +403,17 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
> 
>   
>
> +
> +  
> + Configuration Modules
> + 
> +   Some Perl packages load system-wide configuration from a
> +   dedicated Perl module whose purpose is solely to contain
> +   configuration settings.  The module often contains only variable
> +   settings.  Such modules should be treated as configuration files
> +   and installed under /etc/perl.
> + 
> +  
>  
>  
>  

Seconded.
-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: Digital signature

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

[Russ Allbery]

Niko Tyni  writes:

> The last paragraph seems redundant to me. I suggest dropping it.

> Otherwise it all looks good to me.

Good point.  Here's updated proposed wording.

diff --git a/perl-policy.sgml b/perl-policy.sgml
index 3b76b94..03e5dfb 100644
--- a/perl-policy.sgml
+++ b/perl-policy.sgml
@@ -128,17 +128,27 @@
   
Module Path

- Perl searches three different locations for modules, referred
- to in this document as core in which modules
- distributed with Perl are installed, vendor for
- packaged modules and site for modules installed by
- the local administrator.
+ Perl searches four different locations for modules, referred to
+ in this document as etc for system configuration
+ modules, core in which modules distributed with Perl
+ are installed, vendor for packaged modules,
+ and site for modules installed by the local
+ administrator.


  The module search path (@INC) in the Debian packages
  has been ordered to include these locations in the following
  order:
  
+   etc
+   
+ 
+   Configuration modules (see ).
+   
+/etc/perl
+   
+ 
+   
site (current)

  
@@ -393,6 +403,17 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
  

   
+
+  
+   Configuration Modules
+   
+ Some Perl packages load system-wide configuration from a
+ dedicated Perl module whose purpose is solely to contain
+ configuration settings.  The module often contains only variable
+ settings.  Such modules should be treated as configuration files
+ and installed under /etc/perl.
+   
+  
 
 
 

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Niko Tyni]

On Sat, Jul 17, 2010 at 07:20:55PM -0700, Russ Allbery wrote:
> Ansgar Burchardt  writes:

> > I suggest to add /etc/perl to the list of location in the "Module Path"
> > section.

> Here's an expanded patch that documents what I believe to be the intended
> purpose of adding that to the module search path.  I've copied debian-perl
> for their review as well.

> + Configuration Modules
> + 
> +   Some Perl packages load system-wide configuration from a
> +   dedicated Perl module whose purpose is solely to contain
> +   configuration settings.  The module often contains only variable
> +   settings.  Such modules should be treated as configuration files
> +   and installed under /etc/perl.
> + 
> +
> + 
> +   This applies only to Perl modules whose complete contents is
> +   configuration information, cases where the module file itself is
> +   a configuration file.
> + 

The last paragraph seems redundant to me. I suggest dropping it.

Otherwise it all looks good to me.
-- 
Niko Tyni   nt...@debian.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Ansgar Burchardt  writes:

> perl/5.8.0-7 added /etc/perl to @INC:

>   * Prepend /etc/perl to @INC to provide a standard location for
> configuration modules:

> But this addition has never been documented in the Debian Perl Policy.
> I suggest to add /etc/perl to the list of location in the "Module Path"
> section.

> A simple patch doing so is attached below, but it might be a good idea
> to document what "configuration modules" are and what the "etc" tag
> means (only "core", "vendor" and "site" are explained above, but none of
> those matches the use of /etc/perl).

Here's an expanded patch that documents what I believe to be the intended
purpose of adding that to the module search path.  I've copied debian-perl
for their review as well.

Objections or seconds?

diff --git a/perl-policy.sgml b/perl-policy.sgml
index 3b76b94..bca38f4 100644
--- a/perl-policy.sgml
+++ b/perl-policy.sgml
@@ -128,17 +128,27 @@
   
Module Path

- Perl searches three different locations for modules, referred
- to in this document as core in which modules
- distributed with Perl are installed, vendor for
- packaged modules and site for modules installed by
- the local administrator.
+ Perl searches four different locations for modules, referred to
+ in this document as etc for system configuration
+ modules, core in which modules distributed with Perl
+ are installed, vendor for packaged modules,
+ and site for modules installed by the local
+ administrator.


  The module search path (@INC) in the Debian packages
  has been ordered to include these locations in the following
  order:
  
+   etc
+   
+ 
+   Configuration modules (see ).
+   
+/etc/perl
+   
+ 
+   
site (current)

  
@@ -393,6 +403,23 @@ $(MAKE) install DESTDIR=$(CURDIR)/debian/
  

   
+
+  
+   Configuration Modules
+   
+ Some Perl packages load system-wide configuration from a
+ dedicated Perl module whose purpose is solely to contain
+ configuration settings.  The module often contains only variable
+ settings.  Such modules should be treated as configuration files
+ and installed under /etc/perl.
+   
+
+   
+ This applies only to Perl modules whose complete contents is
+ configuration information, cases where the module file itself is
+ a configuration file.
+   
+  
 
 
 

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Ansgar Burchardt]

Package: debian-policy
Version: 3.9.0.0
Severity: minor

Hi,

perl/5.8.0-7 added /etc/perl to @INC:

  * Prepend /etc/perl to @INC to provide a standard location for
configuration modules:

But this addition has never been documented in the Debian Perl Policy.
I suggest to add /etc/perl to the list of location in the "Module Path"
section.

A simple patch doing so is attached below, but it might be a good idea to
document what "configuration modules" are and what the "etc" tag means (only
"core", "vendor" and "site" are explained above, but none of those matches the
use of /etc/perl).

Regards,
Ansgar

diff --git a/perl-policy.sgml b/perl-policy.sgml
index 3b76b94..8b98ab8 100644
--- a/perl-policy.sgml
+++ b/perl-policy.sgml
@@ -139,6 +139,15 @@
  has been ordered to include these locations in the following
  order:
  
+   etc
+   
+ 
+   Configuration modules.
+   
+/etc/perl
+   
+ 
+   
site (current)

  



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org