<div dir="ltr"><div>I think this thread is starting to veer off course, so let's bring it back home.</div><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div>I ran</div><div><span style="color:rgb(0,0,0);font-family:monospace,'Courier New';font-size:12.7px;line-height:19.05px">dh-make-perl --pkg-perl --build --cpan URL::Encode</span></div>and it ran without errors, and now I have a debian package for the library.<div><br></div><div>What now?</div><div>Kyle</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><a href="http://www.kylehall.info" target="_blank">http://www.kylehall.info</a><br>ByWater Solutions ( <a href="http://bywatersolutions.com" target="_blank">http://bywatersolutions.com</a> )<br>Meadville Public Library ( <a href="http://www.meadvillelibrary.org" target="_blank">http://www.meadvillelibrary.org</a> )<br>Crawford County Federated Library System ( <a href="http://www.ccfls.org" target="_blank">http://www.ccfls.org</a> )<br>Mill Run Technology Solutions ( <a href="http://millruntech.com" target="_blank">http://millruntech.com</a> )<br></div></div>
<br><div class="gmail_quote">On Wed, Mar 9, 2016 at 10:47 AM, Galen Charlton <span dir="ltr"><<a href="mailto:gmc@esilibrary.com" target="_blank">gmc@esilibrary.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Mar 9, 2016 at 7:42 AM, Kyle Hall <span dir="ltr"><<a href="mailto:kyle.m.hall@gmail.com" target="_blank">kyle.m.hall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Also, are you saying any newly packaged libraries *must* make it in to Debian?</div></div></blockquote><div><br></div></span><div>No, I am not saying this.  I said this: "Furthermore, such packages must meet Debian's licensing requirements."</div><div><br></div><div>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 <a href="http://debian.koha-community.org" target="_blank">debian.koha-community.org</a> 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.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Why must packages meet the Debian requirements?<br></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>I should point out that this is not a new guideline.  From the wiki [1]:</div><div><br></div><div>"<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8px;line-height:19.2px">The Koha project is not going to redistribute a module just because it's in CPAN"</span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8px;line-height:19.2px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8px;line-height:19.2px">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. </span></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>This seems like it's adding yet another barrier to entry for new Koha developers.</div></div></div></blockquote><div> </div></span><div>Are new developers actually the primary source of suggestions that we add new CPAN dependencies to Koha?</div><div><br></div><div>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:</div><div><br></div><div>* 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.</div><div>* ensuring Koha's stability for Debian users</div><div>* 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 </div><div>* 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</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div> Now we all need to be Debian package maintainers as well?</div></div></div></blockquote><div><br></div></span><div>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):</div><div><br></div><div>* 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)</div><div>* 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.</div><div>* they can make a request of the Debian Perl Group [3], who are, by all accounts, a pretty helpful bunch</div><div>* they can find a Debian Developer to contract with to build the package</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>It seems like we're taking away one of the most powerful features of Perl, it's extensive library of available modules.</div></div></div></blockquote><div><br></div></span><div>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.</div></div><div><br></div><div>[1] <a href="https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependency_Guidelines" target="_blank">https://wiki.koha-community.org/wiki/Building_Debian_Dependencies/Dependency_Guidelines</a></div><div>[2] <a href="https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines" target="_blank">https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines</a></div><div>[3] <a href="https://pkg-perl.alioth.debian.org/" target="_blank">https://pkg-perl.alioth.debian.org/</a></div><span class=""><div><br></div><div>Regards,</div><div><br>Galen</div>-- <br><div>Galen Charlton<br>Infrastructure and Added Services Manager<br>Equinox Software, Inc. / Open Your Library<br>email:  <a href="mailto:gmc@esilibrary.com" target="_blank">gmc@esilibrary.com</a><br>direct: <a href="tel:%2B1%20770-709-5581" value="+17707095581" target="_blank">+1 770-709-5581</a><br>cell:   <a href="tel:%2B1%20404-984-4366" value="+14049844366" target="_blank">+1 404-984-4366</a><br>skype:  gmcharlt<br>web:    <a href="http://www.esilibrary.com/" target="_blank">http://www.esilibrary.com/</a><br>Supporting Koha and Evergreen: <a href="http://koha-community.org" target="_blank">http://koha-community.org</a> & <a href="http://evergreen-ils.org" target="_blank">http://evergreen-ils.org</a></div>
</span></div></div>
</blockquote></div><br></div>