[Koha-devel] On the way to the Debian package

[Vincent Danjean]

 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 at imag.fr           38330 Montbonnot Saint Martin