[Koha-devel] Packing needs - status to add to bugzilla and the dashboard?

[Kyle Hall]

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 at esilibrary.com> wrote:

> Hi,
>
> On Wed, Mar 9, 2016 at 7:42 AM, Kyle Hall <kyle.m.hall at 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_Guidelines
> [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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160309/a17c6505/attachment.html>