Koha metapackage for easier installs
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§ion=all&arch=any&searc hon=names&keywords=-standalone> §ion=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
After the conversations, I was pro option 4 myself too. Well summarised David. On Wed, 14 Oct 2020, 12:17 am , <dcook@prosentient.com.au> wrote:
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 1. koha-lite (this metapackage installs koha-common) 2. koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 2. Option 2 1. koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 3. Option 3 1. koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 4. Option 4 (David’s Preferred Option) 1. 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.
1. 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§ion=all&arch=any&searchon=names&keywords=-standalone 2. https://packages.debian.org/search?searchon=names&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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Option 4 seems reasonable and is well argumented by David (thanks!) I am for it too Josef On Wed, Oct 14, 2020 at 7:42 AM Renvoize, Martin < martin.renvoize@ptfs-europe.com> wrote:
After the conversations, I was pro option 4 myself too.
Well summarised David.
On Wed, 14 Oct 2020, 12:17 am , <dcook@prosentient.com.au> wrote:
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 1. koha-lite (this metapackage installs koha-common) 2. koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 2. Option 2 1. koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 3. Option 3 1. koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc) 4. Option 4 (David’s Preferred Option) 1. 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.
1. 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§ion=all&arch=any&searchon=names&keywords=-standalone 2. https://packages.debian.org/search?searchon=names&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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Josef Moravec josef.moravec@gmail.com
[Also, maybe later, koha-l10n (or even koha-l10n-es-ar, koha-l10n-es-es, etc.)] Le mer. 14 oct. 2020 à 01:17, <dcook@prosentient.com.au> a écrit :
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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.
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:
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=-standalone https://packages.debian.org/search?searchon=names&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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
koha-common is not koha-core, and that's the main problem koha-common will pull apache2, memcached, zebra-2.0, starman (rabbitmq-server) which should not be in koha-core IMO. Le mer. 14 oct. 2020 à 01:17, <dcook@prosentient.com.au> a écrit :
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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.
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:
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=-standalone https://packages.debian.org/search?searchon=names&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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
there is an option 5. rather than koha-core being a metapackage which installs koha-common - koha-core is reduced version of koha-common, without apache2, memcached, zebra, elastic, starman, rabbitmq, etc... this allows us to define koha-core as we need, without it inheriting all the dependencies of koha-common i think option 4 will not work, because of the problem Jonathan described below On 14/10/20 8:06 pm, Jonathan Druart wrote:
koha-common is not koha-core, and that's the main problem
koha-common will pull apache2, memcached, zebra-2.0, starman (rabbitmq-server) which should not be in koha-core IMO.
Le mer. 14 oct. 2020 à 01:17,<dcook@prosentient.com.au> a écrit :
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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.
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:
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=-standalone https://packages.debian.org/search?searchon=names&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 athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672.
Cheers!
*based on my comment athttps://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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
Oh yes I agree about Option 5 actually. (Except Starman as that's a Perl dependency which should actually be managed by cpanfile rather than debian/control.) Strangely I didn't get Jonathan's email... I have already added an update to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672 but I'm happy to keep iterating on that one until we find just the right thing. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Mason James <mtj@kohaaloha.com> Sent: Thursday, 15 October 2020 2:50 PM To: Jonathan Druart <jonathan.druart@bugs.koha-community.org>; David Cook <dcook@prosentient.com.au> Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha metapackage for easier installs there is an option 5. rather than koha-core being a metapackage which installs koha-common - koha-core is reduced version of koha-common, without apache2, memcached, zebra, elastic, starman, rabbitmq, etc... this allows us to define koha-core as we need, without it inheriting all the dependencies of koha-common i think option 4 will not work, because of the problem Jonathan described below On 14/10/20 8:06 pm, Jonathan Druart wrote:
koha-common is not koha-core, and that's the main problem
koha-common will pull apache2, memcached, zebra-2.0, starman (rabbitmq-server) which should not be in koha-core IMO.
Le mer. 14 oct. 2020 à 01:17,<dcook@prosentient.com.au> a écrit :
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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.
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:
https://packages.debian.org/search?suite=default§ion=all&arch=any &searchon=names&keywords=-standalone https://packages.debian.org/search?searchon=names&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 athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672.
Cheers!
*based on my comment athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c26 6
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
I vote option 5. I would love a way to install the 'core' dependencies in a self contained way, without external services. That would include Starman or whatever server implementation we use. And any 'external' service left outside this koha-core package. El jue., 15 oct. 2020 a las 0:58, <dcook@prosentient.com.au> escribió:
Oh yes I agree about Option 5 actually. (Except Starman as that's a Perl dependency which should actually be managed by cpanfile rather than debian/control.)
Strangely I didn't get Jonathan's email...
I have already added an update to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672 but I'm happy to keep iterating on that one until we find just the right thing.
David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia
Office: 02 9212 0899 Online: 02 8005 0595
-----Original Message----- From: Mason James <mtj@kohaaloha.com> Sent: Thursday, 15 October 2020 2:50 PM To: Jonathan Druart <jonathan.druart@bugs.koha-community.org>; David Cook <dcook@prosentient.com.au> Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha metapackage for easier installs
there is an option 5.
rather than koha-core being a metapackage which installs koha-common - koha-core is reduced version of koha-common, without apache2, memcached, zebra, elastic, starman, rabbitmq, etc...
this allows us to define koha-core as we need, without it inheriting all the dependencies of koha-common
i think option 4 will not work, because of the problem Jonathan described below
koha-common is not koha-core, and that's the main problem
koha-common will pull apache2, memcached, zebra-2.0, starman (rabbitmq-server) which should not be in koha-core IMO.
Le mer. 14 oct. 2020 à 01:17,<dcook@prosentient.com.au> a écrit :
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
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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
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.
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:
https://packages.debian.org/search?suite=default§ion=all&arch=any &searchon=names&keywords=-standalone https://packages.debian.org/search?searchon=names&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
On 14/10/20 8:06 pm, Jonathan Druart wrote: metapackages. packages or standalone applications (like postgresql-common being shared between client and server). However, koha-common has legacy value as a name. libnginx-* packages
I ask that people comment here on the listserv, and ultimately we can
conclude that discussion in Bugzilla athttps:// bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672.
Cheers!
*based on my comment athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c26 6
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Tomás Cohen Arazi Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
Sounds good to me. That’s a good point about Starman actually; Morbo/Hypnotoad are included with Mojolicious, but I suppose we don’t *have* to use Starman. I was thinking too that at some point it would be nice to replace “unzip” with Archive::Zip, “xmlstartlet” with XML::LibXML, and pwgen with some other Perl replacement. Actually, I wonder how far we should take it. Should “koha-core” really only depend on the Perl dependencies? Maybe some of the dependencies like pwgen, sudo, daemon, cron-daemon could be in a “koha-helpers” package as those are for the “koha-*” debian scripts rather than the “Koha” application per se. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Tomas Cohen Arazi <tomascohen@gmail.com> Sent: Thursday, 15 October 2020 9:29 PM To: David Cook <dcook@prosentient.com.au> Cc: Mason James <mtj@kohaaloha.com>; Jonathan Druart <jonathan.druart@bugs.koha-community.org>; koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha metapackage for easier installs I vote option 5. I would love a way to install the 'core' dependencies in a self contained way, without external services. That would include Starman or whatever server implementation we use. And any 'external' service left outside this koha-core package. El jue., 15 oct. 2020 a las 0:58, <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió: Oh yes I agree about Option 5 actually. (Except Starman as that's a Perl dependency which should actually be managed by cpanfile rather than debian/control.) Strangely I didn't get Jonathan's email... I have already added an update to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672 but I'm happy to keep iterating on that one until we find just the right thing. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Mason James <mtj@kohaaloha.com <mailto:mtj@kohaaloha.com> > Sent: Thursday, 15 October 2020 2:50 PM To: Jonathan Druart <jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org> >; David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > Cc: koha-devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] Koha metapackage for easier installs there is an option 5. rather than koha-core being a metapackage which installs koha-common - koha-core is reduced version of koha-common, without apache2, memcached, zebra, elastic, starman, rabbitmq, etc... this allows us to define koha-core as we need, without it inheriting all the dependencies of koha-common i think option 4 will not work, because of the problem Jonathan described below On 14/10/20 8:06 pm, Jonathan Druart wrote:
koha-common is not koha-core, and that's the main problem
koha-common will pull apache2, memcached, zebra-2.0, starman (rabbitmq-server) which should not be in koha-core IMO.
Le mer. 14 oct. 2020 à 01:17,<dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > a écrit :
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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.
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:
https://packages.debian.org/search?suite=default <https://packages.debian.org/search?suite=default§ion=all&arch=any> §ion=all&arch=any &searchon=names&keywords=-standalone 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 athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672> .
Cheers!
*based on my comment athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c26 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c26> 6
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tomás Cohen Arazi Theke Solutions (http://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
I don't think we need to go that far. The trade-off is not that good in terms of efforts vs gain On Thu, Oct 15, 2020, 21:50 <dcook@prosentient.com.au> wrote:
Sounds good to me.
That’s a good point about Starman actually; Morbo/Hypnotoad are included with Mojolicious, but I suppose we don’t **have** to use Starman.
I was thinking too that at some point it would be nice to replace “unzip” with Archive::Zip, “xmlstartlet” with XML::LibXML, and pwgen with some other Perl replacement.
Actually, I wonder how far we should take it. Should “koha-core” really only depend on the Perl dependencies? Maybe some of the dependencies like pwgen, sudo, daemon, cron-daemon could be in a “koha-helpers” package as those are for the “koha-*” debian scripts rather than the “Koha” application per se.
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
*From:* Tomas Cohen Arazi <tomascohen@gmail.com> *Sent:* Thursday, 15 October 2020 9:29 PM *To:* David Cook <dcook@prosentient.com.au> *Cc:* Mason James <mtj@kohaaloha.com>; Jonathan Druart < jonathan.druart@bugs.koha-community.org>; koha-devel < koha-devel@lists.koha-community.org> *Subject:* Re: [Koha-devel] Koha metapackage for easier installs
I vote option 5.
I would love a way to install the 'core' dependencies in a self contained way, without external services. That would include Starman or whatever server implementation we use. And any 'external' service left outside this koha-core package.
El jue., 15 oct. 2020 a las 0:58, <dcook@prosentient.com.au> escribió:
Oh yes I agree about Option 5 actually. (Except Starman as that's a Perl dependency which should actually be managed by cpanfile rather than debian/control.)
Strangely I didn't get Jonathan's email...
I have already added an update to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672 but I'm happy to keep iterating on that one until we find just the right thing.
David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia
Office: 02 9212 0899 Online: 02 8005 0595
-----Original Message----- From: Mason James <mtj@kohaaloha.com> Sent: Thursday, 15 October 2020 2:50 PM To: Jonathan Druart <jonathan.druart@bugs.koha-community.org>; David Cook <dcook@prosentient.com.au> Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha metapackage for easier installs
there is an option 5.
rather than koha-core being a metapackage which installs koha-common - koha-core is reduced version of koha-common, without apache2, memcached, zebra, elastic, starman, rabbitmq, etc...
this allows us to define koha-core as we need, without it inheriting all the dependencies of koha-common
i think option 4 will not work, because of the problem Jonathan described below
koha-common is not koha-core, and that's the main problem
koha-common will pull apache2, memcached, zebra-2.0, starman (rabbitmq-server) which should not be in koha-core IMO.
Le mer. 14 oct. 2020 à 01:17,<dcook@prosentient.com.au> a écrit :
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
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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
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.
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:
https://packages.debian.org/search?suite=default§ion=all&arch=any &searchon=names&keywords=-standalone https://packages.debian.org/search?searchon=names&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
On 14/10/20 8:06 pm, Jonathan Druart wrote: metapackages. packages or standalone applications (like postgresql-common being shared between client and server). However, koha-common has legacy value as a name. libnginx-* packages
I ask that people comment here on the listserv, and ultimately we can
conclude that discussion in Bugzilla athttps:// bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672.
Cheers!
*based on my comment athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c26 6
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--
Tomás Cohen Arazi
Theke Solutions (http://theke.io) ✆ +54 9351 3513384 GPG: B2F3C15F
Looking again at debian/control.in… We do have koha-perldeps for the Perl dependencies, so koha-core could depend on that. Then a koha-script-helpers for /usr/sbin/koha-*script dependencies… * xmlstarlet (I notice misc/cronjobs/backup.sh uses xmlstarlet but ideally it wouldn’t. We could easily replace it with a pure Perl utility.) * sudo * pwgen * mysql-client * daemon * cron-daemon * gettext (? I assume this is used by koha-translate?) External packages used by Koha app (I suppose koha-core would have to have these…): * unzip (replace with Archive::Zip) * C4/ImportExportFramework.pm * tools/picture-upload.pl * tools/upload-cover-image.pl * fonts-dejavu (? Would Koha work without this?) * mysql-client (this could be replaced with a DBI call I suspect) * C4/Context.pm * at (eventually replace this using the task queue) * C4/Scheduler.pm via Scheduler::At Unused in production (these could be part of a koha-build package or something): * yaz (this is really just useful for dev/sysadmin work and isn’t really a requirement) * perl-doc * xsltproc * docbook-xsl (?) * bash-completion * libxml2-utils Unknown?: * debconf (Anyone know what this is used for?) * debhelper (Anyone know what this is used for?) David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of dcook@prosentient.com.au Sent: Friday, 16 October 2020 11:50 AM To: 'Tomas Cohen Arazi' <tomascohen@gmail.com> Cc: 'koha-devel' <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha metapackage for easier installs Sounds good to me. That’s a good point about Starman actually; Morbo/Hypnotoad are included with Mojolicious, but I suppose we don’t *have* to use Starman. I was thinking too that at some point it would be nice to replace “unzip” with Archive::Zip, “xmlstartlet” with XML::LibXML, and pwgen with some other Perl replacement. Actually, I wonder how far we should take it. Should “koha-core” really only depend on the Perl dependencies? Maybe some of the dependencies like pwgen, sudo, daemon, cron-daemon could be in a “koha-helpers” package as those are for the “koha-*” debian scripts rather than the “Koha” application per se. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: Tomas Cohen Arazi <tomascohen@gmail.com <mailto:tomascohen@gmail.com> > Sent: Thursday, 15 October 2020 9:29 PM To: David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > Cc: Mason James <mtj@kohaaloha.com <mailto:mtj@kohaaloha.com> >; Jonathan Druart <jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org> >; koha-devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] Koha metapackage for easier installs I vote option 5. I would love a way to install the 'core' dependencies in a self contained way, without external services. That would include Starman or whatever server implementation we use. And any 'external' service left outside this koha-core package. El jue., 15 oct. 2020 a las 0:58, <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > escribió: Oh yes I agree about Option 5 actually. (Except Starman as that's a Perl dependency which should actually be managed by cpanfile rather than debian/control.) Strangely I didn't get Jonathan's email... I have already added an update to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672 but I'm happy to keep iterating on that one until we find just the right thing. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Mason James <mtj@kohaaloha.com <mailto:mtj@kohaaloha.com> > Sent: Thursday, 15 October 2020 2:50 PM To: Jonathan Druart <jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org> >; David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > Cc: koha-devel <koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Subject: Re: [Koha-devel] Koha metapackage for easier installs there is an option 5. rather than koha-core being a metapackage which installs koha-common - koha-core is reduced version of koha-common, without apache2, memcached, zebra, elastic, starman, rabbitmq, etc... this allows us to define koha-core as we need, without it inheriting all the dependencies of koha-common i think option 4 will not work, because of the problem Jonathan described below On 14/10/20 8:06 pm, Jonathan Druart wrote:
koha-common is not koha-core, and that's the main problem
koha-common will pull apache2, memcached, zebra-2.0, starman (rabbitmq-server) which should not be in koha-core IMO.
Le mer. 14 oct. 2020 à 01:17,<dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > a écrit :
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:
Option 1
koha-lite (this metapackage installs koha-common) koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 2
koha-full (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 3
koha-standalone (this metapackage installs koha-common, MariaDB, Elasticsearch, RabbitMQ, etc)
Option 4 (David’s Preferred Option)
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.
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:
https://packages.debian.org/search?suite=default <https://packages.debian.org/search?suite=default§ion=all&arch=any> §ion=all&arch=any &searchon=names&keywords=-standalone 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 athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26672> .
Cheers!
*based on my comment athttps://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c26 <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22417#c26> 6
David Cook
Software Engineer
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Online: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website :http://www.koha-community.org/ git :http://git.koha-community.org/ bugs :http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ -- Tomás Cohen Arazi Theke Solutions (http://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F
participants (6)
-
dcook＠prosentient.com.au -
Jonathan Druart -
Josef Moravec -
Mason James -
Renvoize, Martin -
Tomas Cohen Arazi