[Koha-devel] Packaging of Koha dependencies

[Fridolin SOMERS]

Perfect, it's good to know this.
You should copy it to a wiki page I think.
Regards,

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/
>

-- 
Fridolin SOMERS
Biblibre - Pôles support et système
fridolin.somers at biblibre.com