Re: [Koha-devel] Koha packaging problems (Deb10/Buster)
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 On Behalf Of dc...@prosentient.com.au Sent: Wednesday, 11 March 2020 2:55 PM To: 'Mason James' ; 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:///debian/dists//". 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- 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 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 > deb http://debian.koha-community.org/koha stretch/19.11 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... >>
Re: [Koha-devel] Koha packaging problems (Deb10/Buster)
It seems like a lot of APT repositories out there follow the structure of "http:///debian/dists//". 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- 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 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 > deb http://debian.koha-community.org/koha stretch/19.11 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]
Re: [Koha-devel] Koha packaging problems (Deb10/Buster)
hi Julian > deb http://debian.koha-community.org/koha stretch/19.11 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/
Re: [Koha-devel] hackfest cancelled
Greetings, > Let's do something remotely that week. +1 to Tomas’ idea. Create a hackfest trello board (like we have done in the past), and then people could IRC with vested parties for particular panels/bugs? GPML, Mark Tompsett___ 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/
Re: [Koha-devel] hackfest cancelled
Hi Paul and all. This was the right decision under the current circumstances. I look forward to meeting you soon; I always enjoyed the Hackfest as THE developer's event. Let's do something remotely that week See you soon! El mar., 10 mar. 2020 a las 6:26, Paul Poulain () escribió: > Hello all, > > In case you were still wondering "should I go to the hackfest this year > ?", I'll answer for you : I've decided to cancel the hackfest. Too sad, > but everyone is better at home, taking care of his family. > > See you soon !!! > > -- > Paul Poulain, Associé-gérant / co-owner > BibLibre, Services en logiciels libres pour les bibliothèques > BibLibre, Open Source software and services for libraries > > ___ > 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/
Re: [Koha-devel] hackfest cancelled
Hey Paul, This is sad news, but I understand the hackfest would not have been the joyful event it is every time. Séverine and I would have stay at home anyway but we intended to “virtualy be there” by doing what we do at this sort of time : testing, signing, failing. Should we try to do it all to advance patches for the next release ? Best regards, -- Nicolas Le mar. 10 mars 2020 à 10:26, Paul Poulain a écrit : > Hello all, > > In case you were still wondering "should I go to the hackfest this year > ?", I'll answer for you : I've decided to cancel the hackfest. Too sad, > but everyone is better at home, taking care of his family. > > See you soon !!! > > -- > Paul Poulain, Associé-gérant / co-owner > BibLibre, Services en logiciels libres pour les bibliothèques > BibLibre, Open Source software and services for libraries > > ___ > 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/ > -- *Nicolas Legrand* Administration technique et développements du système de gestion de la bibliothèque [image: Logo BULAC] Bibliothèque universitaire des langues et civilisations 65 rue des Grands Moulins F-75013 PARIS T +33 1 81 69 *18 22* www.bulac.fr ___ 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] hackfest cancelled
Hello all, In case you were still wondering "should I go to the hackfest this year ?", I'll answer for you : I've decided to cancel the hackfest. Too sad, but everyone is better at home, taking care of his family. See you soon !!! -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries ___ 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/
Re: [Koha-devel] Koha packaging problems (Deb10/Buster)
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 ___ 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] 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 ___ 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/
