Re: Koha packaging problems (Deb10/Buster)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Koha packaging problems (Deb10/Buster)

Julian Maurice
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
> [hidden email]
> 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
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Koha packaging problems (Deb10/Buster)

Mark Tompsett
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

_______________________________________________
Koha-devel mailing list
[hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: Koha packaging problems (Deb10/Buster)

dcook
In reply to this post by Julian Maurice
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 <[hidden email]> On Behalf Of Mason James
Sent: Wednesday, 11 March 2020 12:41 PM
To: [hidden email]
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
>> [hidden email]
>> 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
[hidden email]
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
[hidden email]
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/

signature.asc (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Koha packaging problems (Deb10/Buster)

dcook
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 <[hidden email]> On Behalf Of [hidden email]
Sent: Wednesday, 11 March 2020 2:55 PM
To: 'Mason James' <[hidden email]>; [hidden email]
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 <[hidden email]> On Behalf Of Mason James
Sent: Wednesday, 11 March 2020 12:41 PM
To: [hidden email]
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
>> [hidden email]
>> 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
[hidden email]
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
[hidden email]
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/

signature.asc (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Koha packaging problems (Deb10/Buster)

dcook
In reply to this post by Julian Maurice
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 <[hidden email]> On Behalf Of Mason James
Sent: Thursday, 12 March 2020 8:20 PM
To: Koha Devel <[hidden email]>
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
[hidden email]
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
[hidden email]
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/

signature.asc (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Koha packaging problems (Deb10/Buster)

dcook
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 <[hidden email]>
Sent: Friday, 13 March 2020 6:44 PM
To: [hidden email]; 'Koha Devel' <[hidden email]>
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, [hidden email] 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 <[hidden email]> On
> Behalf Of Mason James
> Sent: Thursday, 12 March 2020 8:20 PM
> To: Koha Devel <[hidden email]>
> 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
> [hidden email]
> 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
[hidden email]
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/

signature.asc (495 bytes) Download Attachment