INN::Config Perl module

[Russ Allbery]

Thank you very much for doing this!

Julien ÉLIE <julien at trigofacile.com> writes:

> * I have created trunk/lib/perl/INN/Config.pm.in (Config.pm
>   is generated at configure time) and trunk/lib/perl/Makefile;
>   a configure option --with-libperl-dir (=${libdir}/perl by
>   default) allows to change the install directory (in case
>   some packages will want to put INN::Config with all the
>   other Perl modules).  Is that OK?

I would create a separate top-level perl directory instead of lib/perl to
keep the directory nesting from getting too extreme, but otherwise that
seems okay to me.

There are two different approaches you can take with installing the
modules: do it ourselves with a configure option, or hook a Makefile.PL
into the configure system.  Right now, with pure Perl modules, we have our
option and that seems okay.  If we add binary modules, though, we'll need
to use the Makefile.PL method, and passing the configure option down to it
may get tricky.

> * I will remove scripts/innshellvars.pl and glue for it,
>   and update everything to use INN::Config instead.
>   Is that all right?

My only worry is that we may want to keep a stub innshellvars.pl around
that exports the same information as the current one for external programs
that use it outside of INN.  I think there may be several of those.  But
that may be tricky to do as well.

> * I cannot use "use strict" in Config.pm because of the
>   evaluation of "innconfval -p" (new variables are not
>   see by Perl and I do not know how to get round that
>   and, first of all, whether it is possible).

There are ways around that by making INN::Config a binary module that
exports variables based on parsing inn.conf, but that's complicated to get
right.  I think this is fine for right now.  One step at a time.

> * In backends/send-uucp.in, there is a call to uustat iff
>   $INN::Config::have_uustat is defined.  But there is no
>   parameter which has this name.  And it makes "perl -w"
>   complain with the new INN::Config.  What should I do?  Drop
>   the reference to uustat or add a search of uustat at
>   configure time and add $have_uustat in Config.pm?

I'm not sure.  Ideally we should probably probe for uustat in configure.ac
so that code actually does something.  It's somewhat useful code.  (I'm
not sure have_uustat would be the best variable to set, though.  I'd
rather set uustat to the path to uustat or undef if it's not found and
make decisions based on that.)

> * In contrib/makeexpctl.in, $oldtime is not defined.
>   I am not sure of what I should put for it.  An idea?

>   $readfile="$INN::Config::pathdb/readgroups";
>   if (open(RDF, $readfile)) {
>     while (<RDF>) {
>       chop;
>       @foo=split(/ /); # foo[0] should be group, foo[1] lastreadtime
> -->   if ($foo[1] < $oldtime) {
>         next; # skip entries that are too old.
>       }
>       $groups{$foo[0]} = $foo[1];
>   }
>   close(RDF);
>   }

That looks like a long-standing bug in that script independent of this
change.  It looks like you should copy the setting of $oldtime from
findreadgroups.in, which is the other half of this system.

> * In control/controlchan.in, there is a reference to INN::Syslog;
>   what is it?  An existing INN Perl module?

It's an existing module that (I think) Marco had written because the
Sys::Syslog Perl module used to be rather broken.  It was never
distributed with INN.  It's a version of Sys::Syslog that always calls the
C API and never tries to create syslog UDP packets itself.  I *think* it's
now unnecessary with current versions of Perl.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.