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, <dc...@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 <m...@kohaaloha.com> > Sent: Thursday, 15 October 2020 2:50 PM > To: Jonathan Druart <jonathan.dru...@bugs.koha-community.org>; David Cook > <dc...@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,<dc...@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/ > > > > _______________________________________________ > 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
_______________________________________________ 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/
