Hi, Thanks for your replies. Here are some comments and then a few more questions. Galen Charlton wrote:
I will apply most of these to the Koha 3.1/3.2 HEAD tomorrow. It may take a bit longer for them to reach the 3.0 maintenance branch. Note that the big permissions patch will not apply as is, since the translated templates are not stored in the git tree but are generated during packaging, but I'll add a substitute.
Thank you very much. I'm not in a hurry to have them in the 3.0 branch: I can work on my local modified copy. But it is not the kind of patch that I would like to maintain in the Debian package. So, knowing it will be present upstream in a future release is perfect for me.
Another problem of the current code is that all manpages generated from koha perl modules are invalid. They are missing the required head lines. [...]
Fixing the POD is better.
I made a little test on one file (the first one). Applying this kind of change seem to be correct: ===================== diff -u AuthoritiesMarc.pm.orig AuthoritiesMarc.pm --- AuthoritiesMarc.pm.orig 2008-08-20 15:44:45.000000000 +0200 +++ AuthoritiesMarc.pm 2008-08-20 15:50:13.000000000 +0200 @@ -60,6 +60,12 @@ ); } +=head1 NAME + +C4::AuthoritiesMarc - useful module to do something + +=head1 DESCRIPTION + =head2 GetAuthMARCFromKohaField =over 4 ===================== You can easily check if it is good by running: pod2man AuthoritiesMarc.pm > /tmp/C4::AuthoritiesMarc.3pm lexgrog /tmp/C4::AuthoritiesMarc.3pm lexgrog should show you the 'NAME' line (and not 'parse failed' as currently) Andrew: lexgrog can perhaps be used on the generated manpage in order to have a test ?
Next, I would like to talk about koha-tmpl/*-tmpl/prog/"lg-LG" directories. I see two things: - there are lots of duplicated files and directories. In the Debian packaging, I'm trying to add a 'common' directory and add symlink from the lang directories. This cannot be done in the upstream git repo as some plateform does not support symlinks. But, if files are really similar (for example all libs/ and js/ directories in koha-tmpl/intranet-tmpl/prog/*), they can be moved elsewhere (a common place) and reference in other files could be adjusted ?
This is a good idea, but might take a while to be implemented.
Ok. So, for now, in the Debian package, I stick with the 'common' directory and symlinks.
- koha-tmpl/*-tmpl/prog/"lg-LG"/{lib,js} contains version of other softwares already packaged by debian (such as libjs-jquery or tinymce2 for example). The final debian package will need to use these packages and not duplicate the code by embeding another version. So, I would like to know * if these codes of other applications have been modified (I hope not)
I'm reasonably sure that we're using stock JQuery, TinyMCE, and YUI. I'm less sure about the JQuery plugins, but I don't see that any of them are currently packaged.
Thanks. The version number is not exactly the same but I hope it is only bug fix.
* where they are called from (so that I can change to call debian package codes)
They're generally invoked via the templates, in lines such as
<script type="text/javascript" src="<!-- TMPL_VAR name="themelang" -->/lib/greybox/AJS.js"></script>
with the exception of YUI:
<script type="text/javascript" src="<!-- TMPL_VAR NAME="yuipath" -->/menu/menu-min.js"></script>
The themelang and yuipath template variables are ultimately set in the call to C4::Output::gettemplate().
The problem is that a *lot* of the HTML templates invoke JavaScript libraries in that fashion, so if the packaging rules allowing setting up symlinks to the canonical locations of the libraries, that may be simplest.
I think I will stick with either symlinks or Redirect in the apache config so that these files seems to come from the same place. I just see that the git repo does not have the languages directory. Can you tell me how (which program) generate them when you build the tarball ? Do you think that these duplicate files in language directory are here by intend (ie you think that one day JQuery, TinyMCE, YUI, ... will be different, depending on the language) or they are here by 'accident' ? To ask differently, are you interested in a patch that add another copy of these files in a common location and try to remove all call to the 'lang' directory ? Letter, another patch removing them from the language directories can be made. (but here, I need to know how these language directories are generated, hence my previous question) Then, I've a few questions about the configuration: - is it possible to have the intranet and the opac on the same host and port in two different web server directories (for example /opac and /intranet) ? I do not think so but it would be better for the Debian package (easier to propose a config out-of-the-box that works as koha package scripts do not have the right to modify apache config) - I see in several INSTALL file that the global configuration must be adjusted so that the default SAX parser would be XML::LibXML::SAX::Parser This knid of adjustment cannot be done by an official Debian package (modification of a config file from another package). But I do not understand why you do not simply use: $XML::SAX::ParserPackage = "XML::LibXML::SAX::Parser"; Adding this line in sax_parser_print.pl and sax_parser_test.pl just after use XML::SAX; works (without updating my global config file in /etc/perl/XML/SAX/ParserDetails.ini) But I do not know where this is really used in Koha (I cannot find other "use XML::SAX;" in the sources. Perhaps, adding the line $XML::SAX::ParserPackage = "XML::LibXML::SAX::Parser"; in all programs (or in a file included by all koha programs) can avoid this global modification ? - installation instructions recommends to install all files with owner koha:koha. I do not really see the point here. If I understand correctly, it can be better to run the zebra user from another user than root. In this case, which files/dirs need to be written by zebrasrv (/var/log/koha, /var/run/koha/zebradb, var/lib/koha/zebradb and ... ?) Is there other programs (crontab ? ...) that it would be better to run under the koha user/group and which files would need to be writable ? I'm right to think that koha web scripts (scripts run by apache to display the webpages) do not write anything on the filesystem (only in the db ?) [including the installer ?] - I'm right thinking that it is impossible (or very difficult and needing manual intervention) to switch between: * zebra and non-zebra installation (ie what happens if a config with zebra is changed to a config without zebra or vice-et-versa ?) * UNIMARC and MARC21 in zebra config If this is the case, I will try to make sure that the only way to switch from one config to the other with the Debian package would be to purge it (ie remove all, including the database) Thank for your patience and your replies. I hope to be able to present you a experimental package next week. Best regards, Vincent -- Vincent Danjean Adresse: Laboratoire d'Informatique de Grenoble Téléphone: +33 4 76 61 20 11 ENSIMAG - antenne de Montbonnot Fax: +33 4 76 61 20 99 ZIRST 51, avenue Jean Kuntzmann Email: Vincent.Danjean@imag.fr 38330 Montbonnot Saint Martin