Lemme just quickly jump in with a "oh hells no" I don't want to be maintaining and watching security updates for 150+ Perl packages. We all have enough work please let's not make more rods for our back Chris On 10 March 2016 7:35:31 am NZDT, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Thanks Paul! That raises an interesting question! That question being, should we be including Pure Perl libraries in our code base ( in some cases ). Our layout is a bit odd where we have our scripts and libraries sharing the same directory. In most projects we'd see our libraries in a "lib" directory. However, that is no technical reasons we couldn't include MARC::Frobnicate in the Koha codebase itself.
Pro: If the version of the library we use works, we know it will continue to work and will not be subject to regressions in newer versions Con: We will need to update our libraries periodically
In essence, this is exactly what we do with our JavaScript libraries such as jQuery and DataTables.
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 12:03 PM, Paul A <paul.a@navalmarinearchive.com> wrote:
At 07:42 AM 3/9/2016 -0500, Kyle Hall wrote:
Also, are you saying any newly packaged libraries *must* make it in to Debian? Can we not host our own packaged libraries on our apt server? Why must packages meet the Debian requirements? This seems like it's adding yet another barrier to entry for new Koha developers. Now we all need to be Debian package maintainers as well? It seems like we're taking away one of the most powerful features of Perl, it's extensive library of available modules.
One of Koha's strengths certainly was, and most probably still is, the ability for an admin to be able to aptitude/apt-get (even yum) dependencies that conform to her o/s. We used to publish "warnings" about using CPAN. Debian trickles down to Ubuntu -- with a possible time-lag -- and these two o/s are perhaps the most used by Koha-based libraries.
If Koha needs to use a custom *library* and there is reticence to put it through the Debian/Ubuntu loop, surely the proper solution is to put it into the Koha environment (package and tarball) where it remains Koha-specific and the remainder of the o/s, including Perl, stays unchanged without potential repercussions on other installed applications/progammes.
This might well also facilitate version control -- each Koha update has the correct libraries in /usr/share/koha/bin, /usr/share/koha/lib/C4, wherever, but not in /usr/lib/perl* (or /usr/bin/perl) (with or without /local/) available to the entire o/s.
This removes any "barrier to entry for new Koha developers", might ease proper installation/upgrade operations and has the potential to obviate obscure security concerns.
Best -- Paul
Just a thought.
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 Tue, Mar 8, 2016 at 6:03 PM, Galen Charlton <gmc@esilibrary.com> wrote: Hi,
On Tue, Mar 8, 2016 at 12:50 PM, Brendan Gallagher < info@bywatersolutions.com> wrote: Do we have a defined role description of responsibility of the Packaging Manager? (I've only read Robin's posts to the mailing list before - is that it?)
We do now, seeded with my view of the position:
https://wiki.koha-community.org/wiki/Project_roles#Packaging_managerÂ
On a side note, the overall page is new; I'm figuring that it might be a useful exercise to outline minimum role responsibilities for all of the named project positions.
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
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com <http://navalmarinearchive.com/>> and < http://UltraMarine.ca <http://ultramarine.ca/>>
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
------------------------------------------------------------------------
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.