I think this thread is starting to veer off course, so let's bring it back home. I simply want edto question our motives and methods. Barriers to entry should be a constant concern us. I think it's important that we stay vigilant and question new requirements for developers. If we never do that, we'll end up with an ecosystem where we have no new developers and our talent pool may dry up. I've reviewed all the wiki pages we have concerning packaging dependencies, and while there is plenty of information, there is no direction. I think URL::Encode is a great example, as it is a simple library with no dependencies other than Carp. I ran dh-make-perl --pkg-perl --build --cpan URL::Encode and it ran without errors, and now I have a debian package for the library. What now? Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com ) On Wed, Mar 9, 2016 at 10:47 AM, Galen Charlton <gmc@esilibrary.com> wrote:
Hi,
On Wed, Mar 9, 2016 at 7:42 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Also, are you saying any newly packaged libraries *must* make it in to Debian?
No, I am not saying this. I said this: "Furthermore, such packages must meet Debian's licensing requirements."
We cannot Debian to accept a package, and we obviously have no particular influence over Debian's release schedule. Consequently, hosting a package either temporarily or permanently on debian.koha-community.org is a valid option for us in case of technical disagreement with Debian or because we want to require a package before it is available on Debian stable. In the long run, however, it is better that such hosting be temporary; as it saves us work to have a dependency be part of Debian.
Why must packages meet the Debian requirements?
So that they have a chance of actually getting into Debian — and so that Koha does not fall into the trap of requiring non-free dependencies for the sake of developer convenience.
I should point out that this is not a new guideline. From the wiki [1]:
"The Koha project is not going to redistribute a module just because it's in CPAN"
At minimum, a CPAN module that is being considered for packaging must meet the Debian Free Software Guidelines [2]; in my opinion, that is non-negotiable given Koha's status as a GPL3+ project. Of course, there are a variety of technical requirements that a package must meet before it would get accepted by Debian, but we have more flexibility there: we can choose to host a package that is DFSG-complaint but is not quite yet ready for prime-time... if we absolutely need to.
This seems like it's adding yet another barrier to entry for new Koha developers.
Are new developers actually the primary source of suggestions that we add new CPAN dependencies to Koha?
Regardless, there are a variety of competing aims at play here, and I submit that the convenience of new developers -- or not so new developers -- does not trump other considerations that include:
* keeping the number of dependencies (and thus, potential vectors for bugs and security exposures) manageable. Each new dependency adds a maintenance cost the project; not necessarily large in and of itself, but it adds up. * ensuring Koha's stability for Debian users * having some assurance that new dependencies are likely to work; if a CPAN module is already packaged for Debian, there's at least some signal that this is the case * for that matter, easing the situation for folks running RHEL who are restricted from installing CPAN modules willy-nilly; there are at least a few such Koha users out there
Now we all need to be Debian package maintainers as well?
No. Somebody who wants to add a CPAN dependency that is not yet packaged for Debian has several avenues to take (assuming that they've triple-checked that a new dependency is actually necessary):
* they can package it themselves (and bluntly, in the case of paid development that is conducted by a commercial entity, I do not view that as an unreasonable expectation that they one way or another arrange to deal with packaging new dependencies that they propose) * they can make a request of various other developers in the Koha community who have experience building packages -- it's not just me who can do it -- although I note that a request works better than a demand. * they can make a request of the Debian Perl Group [3], who are, by all accounts, a pretty helpful bunch * they can find a Debian Developer to contract with to build the package
It seems like we're taking away one of the most powerful features of Perl, it's extensive library of available modules.
CPAN, as with anything else, is subject to Sturgeon's law; using existing Perl packages helps provide a useful quality filter. As far as Debian is concerned, there are almost 3,500 CPAN modules that are already packaged for Jessie. Does this cover everything? No, of course not; but I submit that a project that already has over 150 CPAN dependencies should be cautious about adding new ones.
[1] https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependency... [2] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines [3] https://pkg-perl.alioth.debian.org/
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org