On Thu, Dec 07, 2006 at 09:14:39AM -0800, Joshua Ferraro wrote:
- Should we not specify some modules as optional, but print a warning that some functionality will not be available in the frontend/backend? Eg for: Net::LDAP PDF::API2 PDF::Reuse::Barcode
Yes, that makes sense.
I'm thinking of using the more portable Module::Build instead of ExtUtils::MakeMaker http://www.perl.com/lpt/a/2006/07/13/lightning-articles.html http://search.cpan.org/perldoc?Module::Build http://search.cpan.org/~mschwern/ExtUtils-MakeMaker-6.31/lib/ExtUtils/MakeMa... I'm not sure about all the differences yet, but it seems interesting to try it out.
- Should we register the activated (but optional) functions for later use, like a kind of plugin system?
Cool idea ...
I hope something like this is possible without too much hassle.
I think our goal should be to keep everything related to Koha in a single directory -- so it's completely isolated from the rest of the system ... so koha/etc makes more sense to me.
I think we need to do both, so perhaps we need more than one Makefile.PL: Distributions don't like things in the root for good reasons (LSB/FHS layout compliance, partition diskspace). I'll first work on the distribution package, then see how we can modify that into a self-contained package. Module::Build also has some support for Win32, so that may be another thing to work on by someone. Manual installers can then choose which type of install they want. Out of interest: what actually is the important business case for having a self-contained package, alongside a distribution-oriented package? - ease of install I think there are some problems with this approach, executable paths, module paths and various other paths, manual upgrades, and probably more. - layout simplicity / commercial support (I think this comes at the cost of having to setup/wire all the FS links yourself) - backups (koha knows where the DB is, and can backup it using some script) My savannah account is: Walden Jama Poulsen