> One solution is to use a different location for the set of Perl > modules used by Koha. This avoids any entanglements with existing > Perl installations on the box. It is a very clean soln :) >
We do that for Koha's internal perl modules, and I think it makes sense there, but I would be very against doing it for *external* dependencies. It doesn't avoid entanglements with existing perl installations, because if you have 5.10 installed (e.g. Ubuntu) you already have a different core and @INC. It may keep you out of the CPAN'd module tree, but none of us wants to step in to fill the role of CPAN for generally available modules like DBI, DBD:mysql, etc. Once you stick your own copies of modules in the system somewhere, you're responsible for updating them. At best, we'd be duplicating modules that the system may already have, and in any case *should* have installed properly. Inevitably, versions will fall out of joint and debugging the difference between one side of the system's perl modules and our side's nearly identical modules will be more headache than it is worth. By the same token, if we were to create any modules that were abstracted enough to be generally useful outisde of Koha, then we should post them to CPAN and keep them up to date. This would be like MARC::File or MARC::File::XML, currently maintained by Mike Rylander or Josh, respectively, and certainly useful in more than just one ILS setting. --Joe Atzberger
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
