[Koha-devel] Koha metapackage for easier installs

[dcook at prosentient.com.au]

Hi all,

 

As we add external dependencies to Koha (e.g. MariaDB, Elasticsearch,
RabbitMQ, etc), there are fears that we are making Koha harder to install
for less technical users. 

 

As a result, Jonathan, Tomas, Martin, Mason, and I have been discussing*
creating a Koha metapackage that incudes all of Koha's external
dependencies, so that people can keep installing Koha with a minimum number
of steps. 

 

I think we're at a point where we now need to decide on some names for
metapackages.

 

Mason has already commented that it would be best to leave the current
"koha" and "koha-common" packages as they are and I think that makes sense.
While no one uses the "koha" package, I think there is still a dream of one
day getting Koha into the upstream Debian repositories with that package
name. Likewise, "koha-common" is so common that we had best not change it
any time soon. 

 

Here are some naming options that have been discussed:

 

1.	Option 1

a.	koha-lite (this metapackage installs koha-common)
b.	koha-full (this metapackage installs koha-common, MariaDB,
Elasticsearch, RabbitMQ, etc)

2.	Option 2

a.	koha-full (this metapackage installs koha-common, MariaDB,
Elasticsearch, RabbitMQ, etc)

3.	Option 3

a.	koha-standalone (this metapackage installs koha-common, MariaDB,
Elasticsearch, RabbitMQ, etc)

4.	Option 4 (David's Preferred Option)

a.	koha-core (this metapackage installs koha-common)

                                                               i.      I
would avoid "koha-lite" as it implies a little application whereas Koha is a
large application

                                                             ii.      I
think that koha-common is currently misnamed as it really is more of a
"core" package than a "common" package that is shared among different
packages or standalone applications (like postgresql-common being shared
between client and server). However, koha-common has legacy value as a name.


                                                           iii.      In
time, I'd like to see services like the SIP server, Z3950 responder, etc
broken out of "koha-core" and put into their own packages. Eventually
"koha-common" would just contain a set of core libraries that are shared
amongst different Koha services. This would help with scalability,
especially when using containers and other forms of modern computing. 

b.	koha-full (this metapackage installs koha-common, MariaDB,
Elasticsearch, RabbitMQ, etc)

                                                               i.      I
would avoid "koha-standalone" as I think that it implies a package without
dependencies, whereas ours would have several dependencies and be more in
line with "koha-full". This is based on some searches through Debian repos:

1.	https://packages.debian.org/search?suite=default
<https://packages.debian.org/search?suite=default&section=all&arch=any&searc
hon=names&keywords=-standalone>
&section=all&arch=any&searchon=names&keywords=-standalone
2.	https://packages.debian.org/search?searchon=names
<https://packages.debian.org/search?searchon=names&keywords=-full>
&keywords=-full

                                                             ii.      In
Debian, there is a nginx-full package which installs many components (e.g.
nginx-common, libnginx-mod-http-auth-pam, etc) and there is a nginx-core
package which installs nginx-common and a small subset of libnginx-*
packages

 

I ask that people comment here on the listserv, and ultimately we can
conclude that discussion in Bugzilla at
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672. 

 

Cheers!

 

*based on my comment at
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c266 

 

David Cook

Software Engineer

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20201014/e7972dae/attachment-0001.htm>