deb http://debian.koha-community.org/koha stretch/19.11
Oh I wanted to add too that if management of the APT repository is challenging, perhaps we should look at using additional tools? I haven't used "aptly" before, but I thought about taking a look at it once. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of dcook@prosentient.com.au Sent: Wednesday, 11 March 2020 2:55 PM To: 'Mason James' <mtj@kohaaloha.com>; koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster) It seems like a lot of APT repositories out there follow the structure of "http://<hostname>/debian/dists/<OS distribution>/<main component>". While I don't think we necessarily have to be dogmatic about it, it does seem like most people would expect that kind of repo format? It seems to me it would be easier to add/drop support for a OS distribution following that pattern as well. Rather than saying "we don't support 19.11 for jessie", we could just stop pushing packages for the "jessie" distribution. Of course, that would make it more difficult to track individual versions of Koha, unless we changed "koha-common" to "koha-common-1911" or something like that, which is what you'll find in package repositories for things like PostgreSQL. (This is also how I manage Koha RPMs in my Yum repositories.) That way you're able to define your dependencies at the OS distro level and you're able to add the versions of Koha available for that distro. You could even have "koha-common" or "koha-common-latest" be a metapackage that points to the latest koha-common-XXXX package. (Maybe it's time to drop the koha-common name since it's not really a "-common" kind of package for sharing libraries between other packages anyway.) As for Julian's point about different versions of Koha requiring different versions of Mojolicious... that could be done via the dependencies specified for each koha-common-version package, although supporting different versions of Mojolicious per OS sounds a bit fraught... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Mason James Sent: Wednesday, 11 March 2020 12:41 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster) hi Julian this solution is very clean from a user's perspective - but... it does create a lot more repo setup complexity and effort per release this solution requires that all 3x3 distributions have all packages explicitly added to them, so 3x more package relationships to maintain i think the following is good alternative solution... deb http://debian.koha-community.org/distro [buster/19.11|jessie/18.11|stable/stable|...} deb http://debian.koha-community.org/koha [19.11|18.11|stable|...} the magic of this solution is that most 'distro' distributions will be empty, as there is no problem with them (eg: bullseye/20.05, stretch/19.11, jessie/20.05, etc...) they will continue to install the default packages from the 'koha' repo - currently, only a small number of the distributions will require additional packages (eg: buster/*) - alternative provides the same level of koha+distro combinations - alternative continues to use the existing 'koha' repo for 99% of the packages - alternative has the 'distro' packages located in a different directory, so easier to understand and maintain - only a minimum of 3 distros to update per release cycle, not 3x3 minimum the good news about the extra complexity is we can use jenkins-ci to test/detect any problems before release cheers, Mason On 10/03/20 8:35 pm, Julian Maurice wrote:
Hi,
With the 'distro' repo, won't we have incompatibility problems between the Koha version and the Perl modules versions ? For instance, if Koha 18.11 and 19.11 require 2 different versions of Mojolicious, how would that be solved ?
Another option is to have one repository per Koha version, for instance:
deb http://debian.koha-community.org/koha_19.11 [stretch|buster|bionic|...]
or to add the Koha version to the distribution name
deb http://debian.koha-community.org/koha stretch/19.11
That way we can support every koha/distro combinations we want.
Le 10/03/2020 à 08:08, Mason James a écrit :
Hi Koha devs
We have a dependency problem with the release of debian-10 and the following packages. (debian-11 is ok)
libmojolicious-perl libmojolicious-plugin-openapi-perl libyaml-libyaml-perl
The packages require specific versions to be built for specific debian releases, due to their dependencies. This type of problem has occurred before: an example is the libcryptx-perl/ubuntu-16.04 bug. or elasicsearch with jessie... https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23128
The specifics of the dependency problem are quite complex so I wont bore you unless you really ask :)
It seems the best solution is to create a new 'distro' repo that contains a small number of additional distro-specific packages. This should allow us to support every type of koha/distro (and arch) combination
Here's an example of a Koha sources.list file... (We can name the distro releases/aliases as we please)
deb http://debian.koha-community.org/koha [19.05|19.11|stable|oldstable|oldoldstable] main deb http://debian.koha-community.org/distro [debian9|ubuntu16.04|bionic|ubuntu-oldstable|stable] main
FYI: It's possible to add the distro-specific packages to the existing 'koha' repo, but that should probably be avoided due to managing the extra complexity (its cleaner to separate the two repos imho)
Two other options... 1/ use kc.org debian packages, with cpanminus (or similar) providing the distro specific packages (extra installation steps and complexity) 2/ ignore the problem for now, and accept that older koha/distro combinations will be forced to break
Does anyone have any other solutions that I have missed, or a better solution even?
Cheers, Mason
_______________________________________________ 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/