[Koha] Re: [Koha-devel] For the (non)coder

[COURYHOUSE at aol.com]

an install script would be really nice... drop in the cd and stand back while 
the magic happens!

Ed Sharpe archivist for SMECC


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20011106/80efc2bd/attachment-0001.html