[Koha-devel] Packaging of Koha dependencies

[Robin Sheat]

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,
-- 
Robin Sheat
Catalyst IT Ltd.
✆ +64 4 803 2204
GPG: 5FA7 4B49 1E4D CAA4 4C38  8505 77F5 B724 F871 3BDF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20150522/ed63ebb2/attachment.pgp>