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