<FONT  SIZE=2>an install script would be really nice... drop in the cd and stand back while the magic happens!<BR>
<BR>
Ed Sharpe archivist for SMECC<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">Subj:<B>[Koha] Re: [Koha-devel] For the (non)coder </B><BR>
Date:11/6/01 11:11:32 AM US Mountain Standard Time<BR>
From:<A HREF="mailto:tonnesen@cmsd.bc.ca">tonnesen@cmsd.bc.ca</A><BR>
To:<A HREF="mailto:nsr4n@tetra.mail.virginia.edu">nsr4n@tetra.mail.virginia.edu</A><BR>
CC:<A HREF="mailto:koha-devel@lists.sourceforge.net">koha-devel@lists.sourceforge.net</A>, <A HREF="mailto:koha@lists.katipo.co.nz">koha@lists.katipo.co.nz</A><BR>
<I>Sent from the Internet </I><BR>
<BR>
<BR>
<BR>
<BR>
On Tue, 6 Nov 2001, Nicholas Stephen Rosasco wrote:<BR>
<BR>
&gt; Is there any sort of target goal/date (I know MARC/z39.50 "completeness"<BR>
&gt; is coming along soon -- what a fantastic tool that is!&nbsp; thanks!!!) for<BR>
&gt; getting a new version packaged, and are any translation issues for the<BR>
&gt; database for the new format expected?<BR>
<BR>
Chris, of Katipo fame, is trying to convince me to package up a new<BR>
release.&nbsp; I'll probably give it a shot.&nbsp; There are a couple of technical<BR>
issues that I need to work out:<BR>
<BR>
1.&nbsp; how to start the Z39.50 daemon, and make sure it keeps running.&nbsp; There<BR>
&nbsp;&nbsp;&nbsp; are also some issues that I need to work out with the daemon itself.<BR>
&nbsp;&nbsp;&nbsp; Every once in a while it likes to redo all the old queries.&nbsp; :)<BR>
2.&nbsp; how to install the YAZ and Net::Z3950 packages.<BR>
3.&nbsp; script to update existing Koha databases (very scary!&nbsp; Will probably<BR>
&nbsp;&nbsp;&nbsp; have an option to allow backing up the existing databases before doing<BR>
&nbsp;&nbsp;&nbsp; the upgrade).&nbsp; <BR>
4.&nbsp; Need to move away from DebConf for configuring the Koha package.&nbsp; I<BR>
&nbsp;&nbsp;&nbsp; like debconf, but it just isn't portable enough.&nbsp; In its place I'll<BR>
&nbsp;&nbsp;&nbsp; have a script that needs to be run after installing the package (be it<BR>
&nbsp;&nbsp;&nbsp; deb, rpm, or tarball).<BR>
5.&nbsp; Need to set up a preferences configuration system so that Koha admins<BR>
&nbsp;&nbsp;&nbsp; can change system preferences (like which acquisitions module to use).<BR>
6.&nbsp; Need to give some thought to integrating the two acquisitions modules<BR>
&nbsp;&nbsp;&nbsp; so that librarians can use either one at any time.<BR>
7.&nbsp; Permissions controls.&nbsp; This is a big one.&nbsp; I'm not sure how HDL does<BR>
&nbsp;&nbsp;&nbsp; this, but I have a separate package called K12Admin that I use to<BR>
&nbsp;&nbsp;&nbsp; create accounts for all staff and students in my schools.&nbsp; I use this<BR>
&nbsp;&nbsp;&nbsp; package to populate the membership database of Koha, and to create an<BR>
&nbsp;&nbsp;&nbsp; apache password file for authenticating to the librarian interface.<BR>
&nbsp;&nbsp;&nbsp; How should this be handled in the generic case?&nbsp; I'm guessing that<BR>
&nbsp;&nbsp;&nbsp; there should be a superuser account that gets created when the package<BR>
&nbsp;&nbsp;&nbsp; is installed that has access to everything, and the "Members" section<BR>
&nbsp;&nbsp;&nbsp; needs to be modified to allow passwords to be stored for users, as<BR>
&nbsp;&nbsp;&nbsp; well as librarian permissions to be granted.&nbsp; As I said before, this<BR>
&nbsp;&nbsp;&nbsp; isn't a particular itch of mine, as all of this is taken care of by my<BR>
&nbsp;&nbsp;&nbsp; K12Admin program here.<BR>
<BR>
<BR>
I could probably have a package together this week that didn't take of 1,<BR>
2, 5, 6 or 7.&nbsp; Actually, 7 could be semi-taken care of with the superuser<BR>
idea.&nbsp; Then there would be one account that had access to the librarian<BR>
interface. <BR>
<BR>
Anyway, just some random thoughts to get me moving...<BR>
<BR>
<BR>
Steve<BR>
</BLOCKQUOTE><BR>
<BR>
</FONT></HTML>