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 <[email protected]> Sent: Thursday, 15 October 2020 2:50 PM To: Jonathan Druart <[email protected]>; David Cook <[email protected]> Cc: koha-devel <[email protected]> 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,<[email protected]> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] 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/
