[Koha-devel] RFC - installer changes

[MJ Ray]

"Galen Charlton" <galen.charlton at liblime.com> wrote:
> git repo:
> http://manage-gmc.dev.kohalibrary.com/koha-installer.git

The branch is called "installer" just in case I'm not the only one
struggling to figure that out.  After making a dummy branch for it,
git pull http://manage-gmc.dev.kohalibrary.com/koha-installer.git installer
seems to work.  How do others manage it?

It conflicts with git.koha.org on the following dependencies:-
<<<<<<< HEAD:Makefile.PL
'MARC::Charset' => 0.98,
'MARC::Crosswalk::DublinCore' => 0.03,
'MARC::File::XML' => 0.88,
'MARC::Record' => 2.00,
'MARC::Crosswalk::DublinCore' => 0.02,
=======
'MARC::Charset' => 0.95,
'MARC::File::XML' => 0.86,
'MARC::Record' => 1.38,
>>>>>>> 9e7a7e986b1af05ba36b2a980cdbbd5cc465f4a7:Makefile.PL

Which versions do we need?

Actually, koha.org is a bit buggy on one of those, repeating
MARC::Crosswalk::DublinCore, but the other version differences are odd.

I'd've gone with
'MARC::Charset' => 0.98,
'MARC::Crosswalk::DublinCore' => 0.03,
'MARC::File::XML' => 0.88,
'MARC::Record' => 2.00,
but I think I'd have just messed up the branch by doing so.

There also seem to be missing deps on XML::LibXSLT and Net::Z3950::ZOOM.

I see now it's because of this from later in the email:
> [...] Also, please
> note that my repository was cloned from HEAD almost two weeks ago and
> I have not yet  merged in current work, so please bear that in mind.

Merging is usually a download-time+5-minutes task with git, so that's
a poor excuse to be giving people old development versions, as long as
you don't think HEAD's QA is letting in new breakages!  Although now
you've not been merging HEAD, you've got the conflict above to
resolve...

So I should have branched HEAD from some unspecified past date.

[...rewind...]
> * Prompting for more configuration information during perl Makefile.PL

Has this been done in a way that makes this step difficult to
automate/package?  It looks very similar to repeating some mistakes of
the 2.2 installer.  I think any questions should be asked by a very
simple front-end script that sets variables and then calls a silent
Makefile.PL.  That would also probably make it easier for GUI
installer makers to see what they needed to do.

I'm hesitant to merge this into the other installer branches until I
see how to automate it.

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

> * Replaced glob with a directory walk to identify files to be
> installed (thanks fbcit!).
> * Separation of Zebra configuration and data files in 'standard' mode.
> * Adjustment of Zebra configuration file layout.  All Zebra config
> files in the Koha package are now installed and are available for use;
> the installer now simply sets profilePath to control which MARC and
> language options are in effect.

Yes, those are big improvements.  Thanks to you, fbcit and any others
who helped to develop them!

> * During 'standard' install, ownership of Koha's files can now be
> assigned to a non-root user (which should be different from the httpd
> user, of course).  This allows most Koha server-side administration
> and web design tasks to be done without requiring root access.
> * Files are now installed with u+w.

Is this problematic for suexec users?  (I don't know and haven't
tested it yet.)

[...]
> * 'make test' now enabled

Great!

[...]
> As a consequence, this means that by default use of the PERL5LIB
> environment variable is necessary; 'make install' now prints a message
> suggesting the the user set KOHA_CONF and PERL5LIB in their profile.
> The default koha-httpd.conf now includes both of these variables.
>
> My main reason for doing this by default is that the C4 modules have
> at present no independent use outside of supporting Koha's CGI scripts
> and are intimately tied to the version of those scripts.  Putting them
> in the default @INC will risk problems for users who need to run
> multiple versions of Koha on a box.
>
> Requiring use of PERL5LIB is not perfect, but it should be noted that
> we already have one required environment variable in the form of
> KOHA_CONF.

Only if the config file isn't in the default location in C4::Context,
surely?

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.

[...]
> Related to this, I think it will be useful to consider specifying the
> version number when doing 'use C4::*' from the scripts, and possibly
> consider use of the 'only' pragma [1].

Yes, I think that would be a very good idea and one way to guard
against accidents if the API changes.

Hope that helps,
-- 
MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 -
Webmaster-developer, statistician, sysadmin, online shop builder,
consumer and workers co-operative member http://www.ttllp.co.uk/ -
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/