[Koha-devel] Packaging of Koha dependencies
Julian Maurice
julian.maurice at biblibre.com
Mon May 25 15:04:24 CEST 2015
Hi Robin,
I have a few questions related to bug 13799 [1].
> the easy case
a) As the required version of Mojolicious is in jessie, does this mean
that we don't have to package it for wheezy ? I thought backporting to
wheezy was still needed since jessie was released just a month ago.
> If you don't help out...
b) I understand that packaging Swagger2 has fallen to the bottom of your
queue, and you are requiring help to do it, correct ? If so, I can help,
just tell me.
Apart from that, I think this mail deserves a page in the wiki.
[1] http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13799
Le 22/05/2015 06:11, Robin Sheat a écrit :
> With my package manager hat on, I want to introduce some general
> guidelines for adding dependencies to the Koha project, because some
> recent approaches have been problematic and sucked up a lot more time
> than they should have.
>
> Apologies in advance for the giant wall of text. It's late afternoon on
> a Friday.
>
> First, the easy case:
> * If the dependency you want to add is in wheezy and jessie (being
> aware of versions) already, then that's fine. We try not to
> introduce these within a monthly release unless there's a good
> reason, but for something going into a new major release, that's
> totally OK.
>
> Otherwise:
> * Figure out the minimum version that'll work. Don't just add the
> latest version because that's what you grabbed out of CPAN. If
> it works with a more commonly distributed version then you've
> saved many people a lot of time by declaring that (not just me,
> but anyone trying to use it on other distributions too.) A bit
> more guidance on that here:
> http://mail.librecat.org/pipermail/librecat-dev/2015-May/000380.html
> * If you can reasonably avoid adding a dependency, do it. It's not
> always possible, but some things don't need to be there because
> it saves a few minutes of coding. If it saves you hours, then
> it's probably reasonable to add it.
> * Small, standalone modules will in most cases be easy to deal
> with. Things with many complex dependencies will not. The latter
> may cause backporting the module to be impossible, in which case
> it just won't happen.
> * Point it out to me early, not right before it's going to be
> released. On one hand, I can tell you then if it's going to be
> impossible. On the other, all the testers and QA people will
> have access to the dependency if it's already in the repo when
> it comes time for signing off, making their lives that much
> easier. If I hear that we need a package once it's gone through
> everything (and too often it's QA that points this out to me,
> that's really bad), your patch _will_ be delayed and may miss a
> release.
> * Check the copyright. I'm not going to redistribute a module just
> because it's in CPAN. As far as I can tell, being in CPAN
> doesn't cause a default license to be applied, so if the module
> doesn't have something that says that it can be redistributed,
> the default position is that it is illegal to redistribute it.
> * All modules that I create are submitted into Debian. If they
> don't get into Debian, then they don't get into Koha. Debian is
> pretty strict, so in turn I have to be pretty strict. The reason
> for this is, in part, that it means that the amount of modules I
> have to care about won't (hopefully) just keep getting bigger,
> there's a chance it'll go down too over time.
> * Most modules that are unpackaged have issues that prevent them
> going into debian. These are found by running the "lintian" tool
> over a package. Usually they're quick and easy. Sometimes there
> are a lot of them. If there are a lot of them, I'm going to
> delegate the fixing of them to the people who want this module
> in. I'm happy to coach you through this process and handle the
> basic things, but I don't always have time to spend days
> wrangling your dependency into a good state.
> * I wrote a guide to help you get started here:
> http://wiki.koha-community.org/wiki/Building_Debian_Dependencies
> * If you don't help out with this when necessary, your
> dependency is likely to go to the bottom of my packaging
> queue. If you do, it'll probably be near the top :)
> * To get a feel for something being easy to package, do:
> dh-make-perl --pkg-perl --build --cpan Module::Name
> with the lintian config set up from that wiki page. If you get
> only a few lintian errors (and some you'll see in every case),
> and you get a .deb file out then end, that's a good sign. Even
> better if from there you tidy it up, commit it to alioth, and
> ask me on the relevant bug to have a look over it for you :)
>
> There's a fair bit of stuff here, but essentially the purpose boils down
> to three points:
> 1. my time is limited and some of this is taking away from real
> client work that is needed for Catalyst to be able to sponsor me
> to do this in the first place,
> 2. I don't want to be a bottleneck that slows down your work
> getting into Koha, and
> 3. the more people that have some experience with this stuff, the
> more people can help things get done.
> 1. You can also get your name in lights as a contributor to
> the Debian project this way.
>
> I hope you got this far!
>
> Thanks,
>
>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://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 <julian.maurice at biblibre.com>
BibLibre
More information about the Koha-devel
mailing list