[Koha-devel] RFC - installer changes

[MJ Ray]

"Galen Charlton" <galen.charlton at liblime.com> wrote:
> On 12/13/07, MJ Ray <mjr at phonecoop.coop> wrote:
> > Can _get_value() get stuck in an infinite loop if the supplied
> > $default isn't in $valid_values and STDIN is empty (so prompt returns
> > $default every time)?  OK, it should never happen, but I'd bet it will...
>
> Shouldn't happen (and didn't when I tested it): per EU::MM
> documentation, prompt() detects when it is being run non-interactively
> and automatically supplies the default value. [...]

It doesn't at the moment, but accidents will happen.  _get_value()
doesn't detect when it is being run non-interactively and may keep
asking prompt() and getting the same invalid default value again and
again.  Can we add the supplied default value to the valid values,
just to be sure?

> > Is this problematic for suexec users?  (I don't know and haven't
> > tested it yet.)
>
> According to my reading of Apache suexec guide, u+w is not a problem
> (g+w or o+w are, but the installer does not install any files with
> those modes).  That said, I have not done any testing using suexec
> mode, and would appreciate information from anybody who has.

I'm thinking more of the opac rewriting koha's files if any weakness
is found... I need to think more about this and hammer on it, unless
anyone else has tested it.

[C4 installation to koha or INC]
> > To be clear, I think this is a step backwards.  My goal is for someone
> > running one koha on their own server to be able to install it with the
> > defaults and it to work immediately.  I don't think running multiple
> > versions of Koha on a box is a common requirement except when
> > upgrading and I think people would be happy to mess with PERL5LIB in
> > that situation.
>
> I agree that a default installation should result in a "just works"
> setup of Koha.  I disagree that running multiple Koha instances is an
> uncommon requirement: there are a lot of library consortia and service
> providers who will need to do exactly that.  Even a single library who
> (responsibly) wants to maintain a production instance and one or more
> test instances will often need or want to use the same box.

What case should we be optimising for?  The user who downloads a first
koha and installs it to try it out?  Or the library consortia?

I think those library consortia and service providers (should?) have
sysadmins who can cope with changing the default module path when they
want to run multiple Koha versions (not instances) at once.

Single libraries will probably at least need to copy the database for
test instances, so it just becomes safer to run it on another
(virtual, perhaps) server and not risk the production instance.

> Therefore, I'm not in favor of putting C4 in Perl's built-in @INC by
> default [...]

So how does that comply with the Debian Perl policy, for example?
http://www.fr.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-paths

Anyway, I think a bigger problem is requiring new users to make more
config steps.  Can we optimise this for new first installs?

[specifying the version number when doing 'use C4::*']
> > Yes, I think that would be a very good idea and one way to guard
> > against accidents if the API changes.
>
> This raises the issue of Koha's main software version number.  At
> present, it ostensibly lives in both kohaversion.pl (used by internal
> version checking code) and C4/Context.pm (solely for use by
> Makefile.PL).  That's one place too many, so I've edited
> kohaversion.pl so that it can be used by WriteMakefile()'s
> VERSION_FROM.

I don't recall why kohaversion.pl was added in August when
$C4::Context::VERSION was already there.  Are we stuck with it?
Can we replace it with use C4::Context; return $C4::Context::VERSION?

If we're stuck with it, can we use kohaversion.pl with a versionnumber?
Does it mean we have to add "use kohaversion.pl ..." calls to every
script, rather than appending the version number to use C4::Context?

Puzzled,