[Koha-devel] Packaging of Koha dependencies
Robin Sheat
robin at catalyst.net.nz
Fri May 22 06:11:27 CEST 2015
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>
More information about the Koha-devel
mailing list