[Koha-devel] Koha packaging problems (Deb10/Buster)

Wed Mar 11 05:00:58 CET 2020

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 at lists.koha-community.org> On Behalf Of dcook at prosentient.com.au
Sent: Wednesday, 11 March 2020 2:55 PM
To: 'Mason James' <mtj at kohaaloha.com>; koha-devel at 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 at lists.koha-community.org> On Behalf Of Mason James
Sent: Wednesday, 11 March 2020 12:41 PM
To: koha-devel at 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] 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 at 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 at 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200311/f41a763b/attachment.sig>