[Koha-devel] RFC - installer changes

[Galen Charlton]

Hi,

On 12/17/07, MJ Ray <mjr at phonecoop.coop> wrote:
> "Galen Charlton" <galen.charlton at liblime.com> wrote:
> > On 12/14/07, MJ Ray <mjr at phonecoop.coop> wrote:
> > > "Galen Charlton" <galen.charlton at liblime.com> wrote:
> > > > On 12/13/07, MJ Ray <mjr at phonecoop.coop> wrote:
> > > again.  Can we add the supplied default value to the valid values,
> > > just to be sure?
> >
> > Yep.
>
> OK, so will you commit something like this, or shall I?

I committed a change on 14 December for this.

[snippage re C4]
> Maybe not absent the rest of Koha, but other scripts (think contrib)
> may want to use them later and it would be cleaner if they don't have
> to be installed into koha or with koha-specific details that they
> don't need otherwise.  I think C4 is more than simply organising
> Koha's code - it defines the API used by other developers.

C4 is an API which is generally non-functional if not connected to a
Koha database.  Sorry, I find it rather unlikely that any Koha
contribs that involve Perl code (outside of a consumer of one of the
web services) will be developed or deployed outside of a full Koha
installation.

> > There are several Debian packages for Perl web applications that
> > follow what I'm suggesting and put the application-specific modules
> > under /usr/share/<package>/lib, including request-tracker3.6 (i.e.,
> > RT) and cgiirc.  While not all Perl web-apps do this, there is enough
> > of a precedent.
>
> I'll be disappointed if packaged koha is as much hassle to install
> and get running as RT.  (We're keen RT users, but the debian package
> doesn't make life much simpler IME.)

Once a package is created that includes all of the dependencies, I do
not see why there should be any particular issue.  The only things
that would require manual setup would be presumably

(a) creating the mysql database, since I assume a Debian package
installer wouldn't do this automatically as a matter of policy.
(b) starting Zebra and zebraqueue_daemon (or the cronjob)
(c) tuning the Apache configuration, assuming that Koha is not
necessarily the only web app installed.

> [C4-finding scripts]
> > The upshot is that now, after doing an installation, no environment
> > variables need to be set to use the command-line tools.
>
> Great.  Why should they still have to be set in Apache on single-Koha
> hosts?

Considering that the supplied koha-httpd.conf already does this, I do
not see what the issue is.

> > > 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?
> > I don't know the history, but I do like having some kind of
> > separation, mostly for the trivial reason that the log for
> > C4/Context.pm wouldn't get cluttered with commits that are not really
> > related to Context.pm itself.
>
> So someone make C4::Version if they fancy it.  It seemed cleaner to me
> for C4::Context (which is loaded by everything, to get the
> configuration) to host it.

Yes, I agree that this is the way to go.

> > No, we can still apply the version check to C4::Context by overriding
> > the VERSION method -- we would need to do this anyway, as the VERSION
> > imported from UNIVERSAL.pm croaks only if the requested version is
> > larger than the module's $VERSION. [...]
>
> How? Are you suggesting the C4::Context module will invoke the
> kohaversion.pl script?  So script loads module loads script?
> If so, this really seems a strange way to do it.

That is in fact the current behavior.  However, I thus far have not
found any reason why this is preferable to having a C4::Version
module, so I'm inclined to change this.

> Why would we need to override the VERSION method?  I thought the idea
> was to use only.pm.

I'm experimenting with both approaches.

Regards,

Galen
--
Galen Charlton
Koha Application Developer
LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709