Re: [Koha] Koha ZOOM install
On Wed, Dec 06, 2006 at 09:30:43AM +0000, MJ Ray wrote:
Jama Poulsen <jama@debianlinux.net> wrote:
Oke, I'm going to study the the rel_3_0 sources a bit to see if I could create something resembling a /koha package, after which I'd like to try and automate things if useful and possibble (eventough it may not be stable yet).
Take a look at the Makefile.PL and perldoc ExtUtils::MakeMaker - I'm not sure whether anyone has taken that forwards since my initial work.
I'm now looking at working with the Makefile.PL setup within the rel_3.0 tree. Some first remarks: - I believe "DBD::MySQL" should be named "DBD::mysql" (see: http://cpan.uwinnipeg.ca/module/DBD::mysql) - Any idea how to turn off the (write) tests for DBD::mysql? Or do I have to enter my root password somehwhere in a file? This test requires a running server and write permissions. Please make sure your server is running and you have permissions, then retry. ... t/insertid...........DBI connect('test','',...) failed: Access denied for user: 'root@localhost' (Using password: NO) at t/insertid.t line 13 - Module requirements - Current modules: 'DBI' => 1, 'Date::Manip' => 1, 'DBD::mysql' => 1, 'HTML::Template::Pro' => 1, 'Digest::MD5' => 1, 'MARC::Record' => 2.0, 'MARC::Charset' => 0.95, 'MARC::File::XML' => 0.83, 'Mail::Sendmail' => 1, 'PDF::API2' => 1, 'Net::LDAP' => 1, 'XML::Simple' =>1, 'XML::LibXML' => 1.58 - Extra modules: - Event - Net::Z3950 - Net::YAZ - Class::Accessor - PDF::Reuse::Barcode - Data::Random - Net::Z3950::ZOOM - C4 (and C4::Context) - MARC::Crosswalk::DublinCore - Lingua::Stem - Any other modules I missed? - 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 - Should we register the activated (but optional) functions for later use, like a kind of plugin system? - The "PL_FILES" option usage should not conflict with package distribution things I think, but still allow for a manual install. So maybe there needs to be some trimming there. I need to look more into this. - Would it be a good idea to research into using the "PPM_INSTALL_SCRIPT" option in the Makefile.PL to do other (non-perl module) detection and configuration work before the "make install" step? (Perhaps this has already been discussed on IRC or this list?) External package (detection / configuration) to deal with: - configure Apache / Apache2 - provide a standard includable example that fits with the standard koha setup. - How about a "/etc/koha" directory where we can put the "apache-koha.conf" and the "koha.xml"? - Let the user/distribution activate the config in apache itself. - yaz (versioning important) - zebra server (versioning important) - start/stop/etc. system - configuration - should we put the z3950-daemon-options (or simple call it zebra.conf) in /etc/koha for now? (Until there is some general server package availble.) - Setup the CGI environment (this - see next item. - Setup the non-executable web server documents - Any ideas what would be best to do here? - Perhaps let the user/distribution copy a pre-made set of documents to the web server location, and change the permission. - Anything else that should be done for good packaging? Jama Poulsen
Some more questions/comments... On Wed, Dec 06, 2006 at 01:01:06PM +0100, Jama Poulsen wrote:
- C4 (and C4::Context)
I meant to say just C4, but thats ofcourse Koha's base module. Just wondering: would it have any advantage to make a separate released Perl module out of this? From a API/packaging interface point of view this sounds nice, but I don't know how practical it would really be for the developers. There's often also a delay between the distribution/CPAN package and a new release.
- Any other modules I missed? - CGI - Smart::Comments - LWP::Simple
- The "PL_FILES" option usage should not conflict with package distribution things I think, but still allow for a manual install. So maybe there needs to be some trimming there. I need to look more into this.
What would actually be the best place for files like: - The many Koha perl script executables (and some shell scripts) IMO, the many Koha executables should not "pollute" the main bin namespace for users I think, so they could go into a special bin/koha directory (extra work needed for user to make the executables resolvable), or should they all be suffixed with "koha_"? - SQL data files (/var/lib/koha/sql/ ?) - Data file input and outputs: /var/lib/koha/(import|export) ? - Some kind of script plugin-architecture design would be nice, for the custom- script work (so updates don't trample on these scripts). - Application internal-help texts (and translations), if there are any. (problable in the /usr/share/doc directory or something similar) - Somewhat related: What is the status of mod_perl compliancy? Its says in progress here (but I know how difficult it can be to get this right): http://wiki.koha.org/doku.php?id=en:development:roadmap3.0&s=mod%20perl Jama Poulsen
Hi Jama, Sorry for the silence ... been a busy week. On Wed, Dec 06, 2006 at 01:01:06PM +0100, Jama Poulsen wrote:
On Wed, Dec 06, 2006 at 09:30:43AM +0000, MJ Ray wrote:
Jama Poulsen <jama@debianlinux.net> wrote:
Oke, I'm going to study the the rel_3_0 sources a bit to see if I could create something resembling a /koha package, after which I'd like to try and automate things if useful and possibble (eventough it may not be stable yet).
Take a look at the Makefile.PL and perldoc ExtUtils::MakeMaker - I'm not sure whether anyone has taken that forwards since my initial work.
I'm now looking at working with the Makefile.PL setup within the rel_3.0 tree.
Some first remarks:
- I believe "DBD::MySQL" should be named "DBD::mysql" (see: http://cpan.uwinnipeg.ca/module/DBD::mysql) makes sense.
- Any idea how to turn off the (write) tests for DBD::mysql? Or do I have to enter my root password somehwhere in a file? that seems like a bad idea ... but I'm not sure of the alternative.
This test requires a running server and write permissions. Please make sure your server is running and you have permissions, then retry. ... t/insertid...........DBI connect('test','',...) failed: Access denied for user: 'root@localhost' (Using password: NO) at t/insertid.t line 13
- Module requirements
- Current modules: 'DBI' => 1, 'Date::Manip' => 1, 'DBD::mysql' => 1, 'HTML::Template::Pro' => 1, 'Digest::MD5' => 1, 'MARC::Record' => 2.0, 'MARC::Charset' => 0.95, 'MARC::File::XML' => 0.83, 'Mail::Sendmail' => 1, 'PDF::API2' => 1, 'Net::LDAP' => 1, 'XML::Simple' =>1, 'XML::LibXML' => 1.58
- Extra modules: - Event - Net::Z3950 - Net::YAZ - Class::Accessor - PDF::Reuse::Barcode - Data::Random - Net::Z3950::ZOOM - C4 (and C4::Context) - MARC::Crosswalk::DublinCore - Lingua::Stem
- Any other modules I missed?
Event is no longer needed. Net::Z3950 should be Net::Z3950::ZOOM I'm sure there are others, I'll try to track down a list.
- 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.
- Should we register the activated (but optional) functions for later use, like a kind of plugin system?
Cool idea ...
- The "PL_FILES" option usage should not conflict with package distribution things I think, but still allow for a manual install. So maybe there needs to be some trimming there. I need to look more into this. cool.
- Would it be a good idea to research into using the "PPM_INSTALL_SCRIPT" option in the Makefile.PL to do other (non-perl module) detection and configuration work before the "make install" step? (Perhaps this has already been discussed on IRC or this list?) Good idea ... not sure if anyone's working on that, but I don't recall hearing anything ...
External package (detection / configuration) to deal with:
- configure Apache / Apache2 - provide a standard includable example that fits with the standard koha setup. - How about a "/etc/koha" directory where we can put the "apache-koha.conf" and the "koha.xml"? - Let the user/distribution activate the config in apache itself. 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.
- yaz (versioning important)
very ...
- zebra server (versioning important) - start/stop/etc. system - configuration - should we put the z3950-daemon-options (or simple call it zebra.conf) in /etc/koha for now? (Until there is some general server package availble.)
Not sure about this one ... I'll give it some thought.
- Setup the CGI environment (this - see next item.
- Setup the non-executable web server documents - Any ideas what would be best to do here? - Perhaps let the user/distribution copy a pre-made set of documents to the web server location, and change the permission.
/me doesn't have an opinion on that ... anyone else?
- Anything else that should be done for good packaging? Well for one, you need CVS access ;-). Send me your username on savannah and I'll set that up.
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
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
participants (2)
-
Jama Poulsen -
Joshua Ferraro