OK, I'm just posting a quick update regarding Debian packaging. Let's keep all the discussion on koha-devel@nongnu.org for now, I think it is appropriate at this early stage. Please subscribe there if you aren't yet. If we get too noisy for that list, we can move to another list when needed. I think Joshua's idea of pulling 2.2.6 (from CVS?) is probably the right one to start with. I think we should maintain our own repository. I think it makes sense to keep the Debian packaging stuff somewhere separate from the main code and merge back whatever work makes sense to the main repository. I've always wanted to try out bzr and I've created my own bzr repository of 2.2.5 (not published atm). Meanwhile, Geoff Crompton has submitted an alioth project request. What do people think? I'm happy to use alioth, and happy that Geoff's taken the initiative to organise it. Geoff, what is the status of the project application? Meanwhile, MJ Ray has suggested: " I think there's a package called something like dpkg-cpan which we should use to package the modules (with names like libperl-marc-record) and then bend the main koha system to do an auto-install into debian/tmp." (Just to clarify, are you talking about modules external to koha that need to be pulled from CPAN or are you talking about parts of koha which could be modularised? I guess you are talking about external dependencies. When I installed Koha 2.2.5 on debian testing my recall is that I didn't need to pull anything from CPAN, everything needed was already in Debian. eg. there is a libmarc-record-perl package already in standard Debian. My recall could be wrong, I might have pulled some stuff from CPAN) MJ Ray also suggests: appoint our debian-perl advisor (someone who subs to that mailing list, relays questions and/or points out where we're getting the perl policy wrong). Anyone volunteering? Who's already on debian-perl? If there is already more than one of us who follow or are willing to follow that list that would be good. And then the main task is to actually produce a package. From my point of view the main task is hacking on the install script to get it to install the package to an arbitrary location (so it can be easily packaged). If anyone wants to give this a go feel free. Also making sure we ultimately install to FHS compliant locations. I'm comfortable with doing the actual packaging once the install script can install to an arbitrary temp location. I'll probably give it a go in the weekend if no-one else does before then. I'm showing my ignorance here, but two things would help me. 1. pointer to a good resource on "learning perl in 24 hours" (I do C, python, shell, awk etc, but never learned perl). 2. A very quick high level overview of what the install script actually does (or a pointer to documentaion). Thanks everyone for your help, Alex Joshua Ferraro wrote:

I think 2.2.6 would be a better choice as there are quite a bug fixes and functional improvements.

I'm all for modifying the perl code to make it more cpan-ish

... Lets keep this discussion on the main list for now.

Kudos for getting serious.

Cheers,

Alex King <alex@king.net.nz> wrote:

I think we should maintain our own repository. I think it makes sense to keep the Debian packaging stuff somewhere separate from the main code and merge back whatever work makes sense to the main repository. I've always wanted to try out bzr and I've created my own bzr repository of 2.2.5 (not published atm).

I have git, tla and cvs installed, but I'm happy to install bzr if needed. I'm really -ve on svn and I failed to install darcs (its Haskell compiler seems to need a Haskell compiler installed). I guess we just want to keep the debian/ directory in it and take the rest from CVS?

Meanwhile, Geoff Crompton has submitted an alioth project request. What do people think?

I'm happy to use alioth if it doesn't limit us. Of course, once the packages get into debian, we should use bugs.debian.org and packages.qa.debian.org as our first line.

(Just to clarify, are you talking about modules external to koha that need to be pulled from CPAN or are you talking about parts of koha which could be modularised? I guess you are talking about external dependencies.

Yes, external deps. I've only been installing koha on stable, so maybe they are all covered now. Thanks to Geoff remembering that the tool's called dh-make-perl.

And then the main task is to actually produce a package. From my point of view the main task is hacking on the install script to get it to install the package to an arbitrary location (so it can be easily packaged).

The install script already supports prefix, etcdir and auto-install, so I doubt much hacking is required. (I added prefix and etcdir some time ago and I think Paul added the auto-install hooks during 2.2.)

If anyone wants to give this a go feel free. Also making sure we ultimately install to FHS compliant locations. [...]

That reminds me: there is a draft debian-webapps policy out there at http://people.debian.org/~seanius/policy/ and one about DB apps at http://people.debian.org/~seanius/policy/dbapp-policy.html/

I'll probably give it a go in the weekend if no-one else does before then. I'm showing my ignorance here, but two things would help me. 1. pointer to a good resource on "learning perl in 24 hours" (I do C, python, shell, awk etc, but never learned perl).

Perl's actually fairly good at coming with introductions, which is partly why it's so popular. Try starting with: man perlintro man perlmod man perlboot man DBI which will probably get you 95% of koha. Unfortunately, it's not always clear to me when koha is just using modules and when it's being OO.

2. A very quick high level overview of what the install script actually does (or a pointer to documentaion).

The body of the installer script is mostly function calls to Install.pm, so it should be fairly clear. Let me know if you want a run-through on IRC some time. Thanks for taking a lead on this. I think I'll be back online properly next week, telco permitting. Best wishes, -- MJ Ray - see http://mjr.towers.org.uk/email.html Somerset, England. Work: http://www.ttllp.co.uk/ IRC/Jabber/SIP: on request

MJ Ray wrote:

Alex King <alex@king.net.nz> wrote:

...

And then the main task is to actually produce a package. From my point of view the main task is hacking on the install script to get it to install the package to an arbitrary location (so it can be easily packaged).

The install script already supports prefix, etcdir and auto-install, so I doubt much hacking is required. (I added prefix and etcdir some time ago and I think Paul added the auto-install hooks during 2.2.)

I see "my $etcdir = $ENV{etcdir}||'/etc';" in installer.pl, but nothing about prefix? These set the install locations? They get hard coded into just /etc/koha.conf and /etc/koha-httpd.conf? Is it possible to use /etc and /usr and still install files actually under debian/koha (debian/tmp is depreciated)? Talking with Chris he says installer.pl does everything including database initialisation. I see looking at it that it tries to find the hostname (perhaps to customise koha-httpd.conf?) These functions need to be split in two - actually moving files into place to be done during packaging, and /etc and database initialisation during install. I see the comment "...does not support a completely automated setup" I would like to be able to ask most/all of the installer questions through debconf or go with defaults. I'm not experienced enough with library/koha systems to have a really good feel for how we should cater for package users and customising their installs. My gut feeling is that most of the package users will be inexperienced like I am and wanting a "default" install suitable for a small library and not wanting too many questions about setup. Those questions maybe could be asked with a lower debconf priority. OTOH library people might want to have control over those settings and not have the debian experience to change the debconf priority.

...

2. A very quick high level overview of what the install script actually does (or a pointer to documentaion).

The body of the installer script is mostly function calls to Install.pm,

Yes I see that. It really just raises more questions for me though :)

so it should be fairly clear. Let me know if you want a run-through on IRC some time.

Yes, I'd like that. I'm available roughly 5pm - 12pm NZDT most days, or pretty much any time by arrangement. Let me know when would suit you. Thanks for your help Alex King

Apologies for not actually getting past the "thinking about it" stage yet. I'm having problems with my Round Tuit. MJ Ray wrote:

It may be better for debian/rules to ignore the installer, TBH, which would help with the CPANisation. I'm not sure it's still worth the effort.

Yes I was thinking about ignoring the installer.pl in debian/rules, where we basically just have to copy stuff around. installer.pl asks some questions first (to find out install locations), and creates koha.conf using those locations as well as copying the files. We must do the coping at package build, and everthing in koha.conf is also set at package build time except the db details (name, host, user, password). So creating koha.conf with a very simple script at install time is no problem either. One question that is asked by the installer is the web template to use, default or NPL? I see from a quick glance that both templates appear to be installed on disk in my install? Is the template chosen by a datebase entry (or entries) as opposed to a different filesystem layout or symlinks etc? It would be good if the template selection was completely in the db/config files and didn't imply a different file layout, it will make it simpler to package.

...

These functions need to be split in two - actually moving files into place to be done during packaging, and /etc and database initialisation during install.

OK. I think there's a third step of entering the librarian's defaults, which could be done mostly after install from the web interface. I think we only ask a few librarian questions in the installer (MARC starter, branch and printer) and they'd be better left until later.

The MARC stuff worries me a bit because I don't understand it. I see traffic regarding upgrading (to rel_3?) saying perhaps "you'll have an easier upgrade if MARC was set up so... and your data was consistently thus..." Having some foreknowledge of what 3.0 will look like, can we encourage people in a certain direction so that a later upgrade to a 3.0 package will be easier? Can we ask debconf questions in such a way that they are easy to map to 3.0 so we can use the answers to suggest defaults in an upgrade? I have a feeling that there is quite a lot of questions which relate to db setup and this will be the greater part of the work of packaging. I think we should have a db setup script which can be run from postinst if the user wants, or can alternatively be run standalone. Ie, a debconf question in postinst which asks "Do you want to set up the database now, or later?" We don't necessarily want a dependancy on mysql-server, because some installations may have the db server on a different machine from where the koha package is installed. Even if the there were a dependency on mysql-server, the server may not be started when we are running postinstall. The separate db initialisation script also gives the user a way to "start again" with a fresh koha system if they make a mistake the first time around, without needing to remove the package and re-install. They can just drop the existing db (or rename it, or just create a new one under a different name) and re-run the db initialisation script. This can be documented in a readme with a note in a debconf message... The db setup script needs to create /etc/koha.conf if it doesn't exist, or tell the user to manually modify it with the correct db paramaters if it does. I think your idea of leaving what we can out of the install and doing it post install via the web interface is also a good one, once again we need to document this for people in README.Debian and/or other appropriate places.

...

[...] I'm available roughly 5pm - 12pm NZDT most days, or pretty much any time by arrangement. Let me know when would suit you.

I think 0730-0930 UTC (=~ 8.30-10.30pm NZDT?) would be best for me. I'll try to hop on over the next few days at that time.

Thanks,

I'll try to hop on IRC tomorrow. Alex