Koha packaging problems (Deb10/Buster)
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
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/
-- Julian Maurice BibLibre
Greetings,
or to add the Koha version to the distribution name deb http://debian.koha-community.org/koha stretch/19.11
+1 Minimal changes to documentation, repo files, and very clear. It would also go to clarify which version of OS is still supported. "What do you mean there is no wheezy?! I can't keep ramming the new version into my old OS?!" GPML, Mark Tompsett
deb http://debian.koha-community.org/koha stretch/19.11
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/
deb http://debian.koha-community.org/koha stretch/19.11
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/
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/
On 10/03/20 8:08 pm, Mason James wrote:
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
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
some other points i didnt mention... koha on buster has a security bug. the solution requires some packages to be updated i can push the packages to the koha repo to fix this problem, but... (there's always a but) the new packages will break jessie :/ when jessie-lts support officially finishes on 30th june 2020, i can happily push these packages - but between now and 30th june we need to decide on a fix for the security bug on buster https://wiki.debian.org/LTS some other options... 3/ do nothing and tell people to not use buster, until june 4/ provide buster packages in an separate repo, until june 5/ provide instructions to add buster packages using cpanm, until june 6/ update koha repo to fix buster, and provide jessie packages in an separate repo 7/ update koha repo to fix buster, and provide instructions to add jessie packages using cpanm 8/ submit required buster packages to debian buster-backports repo (not sure how difficult this is) i prefer option 4/, as its the least disruptive for users, and only requires an extra sources.list line to implement also... i think we should hold off on redesigning the koha apt repository until *after* this buster security issue is fixed cheers, Mason
On 12/03/20 12:43 am, Mason James wrote:
On 10/03/20 8:08 pm, Mason James wrote:
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 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 some other points i didnt mention...
koha on buster has a security bug. the solution requires some packages to be updated
i can push the packages to the koha repo to fix this problem, but... (there's always a but) the new packages will break jessie :/ when jessie-lts support officially finishes on 30th june 2020, i can happily push these packages - but between now and 30th june we need to decide on a fix for the security bug on buster https://wiki.debian.org/LTS
some other options... 3/ do nothing and tell people to not use buster, until june 4/ provide buster packages in an separate repo, until june 5/ provide instructions to add buster packages using cpanm, until june 6/ update koha repo to fix buster, and provide jessie packages in an separate repo 7/ update koha repo to fix buster, and provide instructions to add jessie packages using cpanm 8/ submit required buster packages to debian buster-backports repo (not sure how difficult this is)
i prefer option 4/, as its the least disruptive for users, and only requires an extra sources.list line to implement
also... i think we should hold off on redesigning the koha apt repository until *after* this buster security issue is fixed
cheers, Mason
hmm, i had forgotten another... its possible to tell apt to prefer koha's older mojo v7 package, rather than the newer debian/buster mojo v8 package running the following command before 'apt install koha-common' makes it possible to run the various koha releases on debian 10 $ sudo cat << EOF > /etc/apt/preferences.d/koha-1001 Package: libjson-validator-perl Pin-Priority: 1001 Pin: release o=Koha Package: libmojolicious-perl Pin-Priority: 1001 Pin: release o=Koha EOF for me, this option is probably the easiest workaround for koha on debian 10 if nobody objects? - i am happy to update the koha wiki with this workaround cheers, Mason
Wait a minute... why do we need to pin libmojolicious-perl? Thanks to Ere's work on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22522, Koha should be able to work with Mojolicious 8 now (and Mojolicious::Plugin::OpenAPI 2.21 and JSON::Validator 3.18). Admittedly it's only in master right now, but I'm using his patches on 18.11 and 19.11 already with Mojolicious 8, and they're working well so far. So hopefully people start pushing that code to stable branches ASAP. 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: Thursday, 12 March 2020 8:20 PM To: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster) On 12/03/20 12:43 am, Mason James wrote:
On 10/03/20 8:08 pm, Mason James wrote:
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 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 some other points i didnt mention...
koha on buster has a security bug. the solution requires some packages to be updated
i can push the packages to the koha repo to fix this problem, but... (there's always a but) the new packages will break jessie :/ when jessie-lts support officially finishes on 30th june 2020, i can happily push these packages - but between now and 30th june we need to decide on a fix for the security bug on buster https://wiki.debian.org/LTS
some other options... 3/ do nothing and tell people to not use buster, until june 4/ provide buster packages in an separate repo, until june 5/ provide instructions to add buster packages using cpanm, until june 6/ update koha repo to fix buster, and provide jessie packages in an separate repo 7/ update koha repo to fix buster, and provide instructions to add jessie packages using cpanm 8/ submit required buster packages to debian buster-backports repo (not sure how difficult this is)
i prefer option 4/, as its the least disruptive for users, and only requires an extra sources.list line to implement
also... i think we should hold off on redesigning the koha apt repository until *after* this buster security issue is fixed
cheers, Mason
hmm, i had forgotten another... its possible to tell apt to prefer koha's older mojo v7 package, rather than the newer debian/buster mojo v8 package running the following command before 'apt install koha-common' makes it possible to run the various koha releases on debian 10 $ sudo cat << EOF > /etc/apt/preferences.d/koha-1001 Package: libjson-validator-perl Pin-Priority: 1001 Pin: release o=Koha Package: libmojolicious-perl Pin-Priority: 1001 Pin: release o=Koha EOF for me, this option is probably the easiest workaround for koha on debian 10 if nobody objects? - i am happy to update the koha wiki with this workaround 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/
we need to pin on buster because the current combination of libmojolicious-plugin-openapi-perl (1.15~koha) and libmojolicious-perl (8.12) packages that buster pulls are incompatible with each other - even with bz 22522 applied, this problem still exists on buster we can fix buster by uploading a new version of libmojolicious-plugin-openapi-perl (2.20) to the koha repo, but this breaks jessie - so we cant do that until 30th june ...or do we decide to upload a new version of libmojolicious-plugin-openapi-perl to the koha repo now, and break jessie to fix buster? any other ideas? On 13/03/20 11:36 am, dcook@prosentient.com.au wrote:
Wait a minute... why do we need to pin libmojolicious-perl?
Thanks to Ere's work on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22522, Koha should be able to work with Mojolicious 8 now (and Mojolicious::Plugin::OpenAPI 2.21 and JSON::Validator 3.18). Admittedly it's only in master right now, but I'm using his patches on 18.11 and 19.11 already with Mojolicious 8, and they're working well so far. So hopefully people start pushing that code to stable branches ASAP.
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: Thursday, 12 March 2020 8:20 PM To: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster)
On 12/03/20 12:43 am, Mason James wrote:
On 10/03/20 8:08 pm, Mason James wrote:
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 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 some other points i didnt mention...
koha on buster has a security bug. the solution requires some packages to be updated
i can push the packages to the koha repo to fix this problem, but... (there's always a but) the new packages will break jessie :/ when jessie-lts support officially finishes on 30th june 2020, i can happily push these packages - but between now and 30th june we need to decide on a fix for the security bug on buster https://wiki.debian.org/LTS
some other options... 3/ do nothing and tell people to not use buster, until june 4/ provide buster packages in an separate repo, until june 5/ provide instructions to add buster packages using cpanm, until june 6/ update koha repo to fix buster, and provide jessie packages in an separate repo 7/ update koha repo to fix buster, and provide instructions to add jessie packages using cpanm 8/ submit required buster packages to debian buster-backports repo (not sure how difficult this is)
i prefer option 4/, as its the least disruptive for users, and only requires an extra sources.list line to implement
also... i think we should hold off on redesigning the koha apt repository until *after* this buster security issue is fixed
cheers, Mason hmm, i had forgotten another... its possible to tell apt to prefer koha's older mojo v7 package, rather than the newer debian/buster mojo v8 package
running the following command before 'apt install koha-common' makes it possible to run the various koha releases on debian 10
$ sudo cat << EOF > /etc/apt/preferences.d/koha-1001 Package: libjson-validator-perl Pin-Priority: 1001 Pin: release o=Koha
Package: libmojolicious-perl Pin-Priority: 1001 Pin: release o=Koha EOF
for me, this option is probably the easiest workaround for koha on debian 10
if nobody objects? - i am happy to update the koha wiki with this workaround
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/
Hmm that is tricky. I've run through a few different scenarios in my head but they all have pros and cons. No obvious winner. I think maybe your idea of a main Koha repo and separate Debian specific repos is the best compromise. That way all supported Linux distros can gets access to all supported Koha versions. Right? 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: Mason James <mtj@kohaaloha.com> Sent: Friday, 13 March 2020 6:44 PM To: dcook@prosentient.com.au; 'Koha Devel' <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster) we need to pin on buster because the current combination of libmojolicious-plugin-openapi-perl (1.15~koha) and libmojolicious-perl (8.12) packages that buster pulls are incompatible with each other - even with bz 22522 applied, this problem still exists on buster we can fix buster by uploading a new version of libmojolicious-plugin-openapi-perl (2.20) to the koha repo, but this breaks jessie - so we cant do that until 30th june ...or do we decide to upload a new version of libmojolicious-plugin-openapi-perl to the koha repo now, and break jessie to fix buster? any other ideas? On 13/03/20 11:36 am, dcook@prosentient.com.au wrote:
Wait a minute... why do we need to pin libmojolicious-perl?
Thanks to Ere's work on https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22522, Koha should be able to work with Mojolicious 8 now (and Mojolicious::Plugin::OpenAPI 2.21 and JSON::Validator 3.18). Admittedly it's only in master right now, but I'm using his patches on 18.11 and 19.11 already with Mojolicious 8, and they're working well so far. So hopefully people start pushing that code to stable branches ASAP.
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: Thursday, 12 March 2020 8:20 PM To: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster)
On 12/03/20 12:43 am, Mason James wrote:
On 10/03/20 8:08 pm, Mason James wrote:
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 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 some other points i didnt mention...
koha on buster has a security bug. the solution requires some packages to be updated
i can push the packages to the koha repo to fix this problem, but... (there's always a but) the new packages will break jessie :/ when jessie-lts support officially finishes on 30th june 2020, i can happily push these packages - but between now and 30th june we need to decide on a fix for the security bug on buster https://wiki.debian.org/LTS
some other options... 3/ do nothing and tell people to not use buster, until june 4/ provide buster packages in an separate repo, until june 5/ provide instructions to add buster packages using cpanm, until june 6/ update koha repo to fix buster, and provide jessie packages in an separate repo 7/ update koha repo to fix buster, and provide instructions to add jessie packages using cpanm 8/ submit required buster packages to debian buster-backports repo (not sure how difficult this is)
i prefer option 4/, as its the least disruptive for users, and only requires an extra sources.list line to implement
also... i think we should hold off on redesigning the koha apt repository until *after* this buster security issue is fixed
cheers, Mason hmm, i had forgotten another... its possible to tell apt to prefer koha's older mojo v7 package, rather than the newer debian/buster mojo v8 package
running the following command before 'apt install koha-common' makes it possible to run the various koha releases on debian 10
$ sudo cat << EOF > /etc/apt/preferences.d/koha-1001 Package: libjson-validator-perl Pin-Priority: 1001 Pin: release o=Koha
Package: libmojolicious-perl Pin-Priority: 1001 Pin: release o=Koha EOF
for me, this option is probably the easiest workaround for koha on debian 10
if nobody objects? - i am happy to update the koha wiki with this workaround
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/
participants (4)
-
dcook＠prosentient.com.au -
Julian Maurice -
Mark Tompsett -
Mason James