MJ --
I do not see why you want to reimplement. I would prefer to upgrade. Some of the things the installer needs to do are fiddly, as we've discovered wrinkles in the past.
Apologies. I should have been more clear. I do not want to rewrite the entire installer procedure. I want to use the existing code and modify it. The code that actually does the installation seems to work well enough. I'm not sure why I used the word "reimplement." I suspect because it was a little bit after midnight and I was exhausted... I'll let that be a lesson to me, and in the future try to remember to wait to send messages to the list until the morning.
* File installation and configuration should be separate from each other (necessary for creating a port compliant with the FreeBSD ports system's unspoken best practices, and probably other packaging systems' best practices as well)
If it's undocumented, how will we know if we do it "right"?
In this case, because a major part of the test procedure for a port is to build, install, uninstall, and reinstall the port on an unattended server farm. Any user intervention will prevent it from doing so.
* Configuration should be possible at any time after installation (so on systems where the sysadmin is not also the Koha admin, the sysadmin doesn't have to wait for the Koha admin)
Can you elaborate on this, please?
Certainly. I don't know how common this is, but I worked at a company where one of my coworkers was the sysadmin, and I did the web server configuration separately, after he had finished intalling the software. I'm thinking about a situation like that, where the sysadmin may only install Koha and expect someone else to configure Koha. The configuration option that made me think of that was the installation of the MARC tables. A sysadmin wouldn't necessarily know what MARC is.
* It should be possible to specify ALL options to the installation and configuration scripts using command line switches or environment variables, or something else that doesn't require user intervention (so that the setup process for the entire system could be scripted [I've done this, so I imagine other people do it too]; the auto-configuration file doesn't really lend itself to scripting, in my opinion)
I'm still looking at the auto_install part. Why do you think it "doesn't really lend itself to scripting"?
It would make any "meta-installer" depend on an additional file, and, more importantly, there are no accessor functions for it, besides writing something that will parse it, so reading in the file to display your options from the meta-installer, for example, would be difficult. Right? Did I miss something here?
Specifying all options in the environment/command-line would be a bad idea for security, as there are passwords which you don't want visible on the output of ps.
Oh dear. I hadn't thought of that. Any suggestions besides an auto_install file? Or suggestions about how to deal with the above objections about auto_install files? Or, even better, an explanation of how my objections were based on incorrect information?
* It should be possible to install Koha without having GRANT privileges on the MySQL server (or root access to the server), if an account has already been created for Koha's use
This would be a good addition, but koha should use an opac account different from the librarian one. I know you can circumvent that if there's only one account, but it must be supported.
What about giving the option of specifying two accounts, one for the OPAC and one for the Librarian?
My plan is to start by separating the installation and configuration into two separate scripts, both using the Install.pm module. I am not sure how to implement the second issue. Perhaps have the installation set up the intranet module temporarily, and then use a one-time web-based configurator a la Refbase (refbase.sourceforge.net)?
Install.pm really should try to use only core perl modules at first, IMO. I think past maintainers probably agreed, as things are fed to mysql tools rather than using DBI. It may be worth reconsidering the approach to this, as command line behaviour differs between platforms.
It's something to think about. That would be the last change I would implement, actually, I think, being the largest.
My first thought was to install the Install.pm module in site_perl and the configuration script in $PREFIX/sbin (for example), but I guess installing anything outside of Apache's area should be avoided?
Why?
Because fundamentally Koha is a web application that runs in Apache, and not a system package. If you don't think this is a problem, though, I'd certainly not argue with you.
Any thoughts on this? Anything I've suggested that is a Really Bad Idea? Anything that should be done differently than I suggested? Anything that you'd like to see implemented in the installer? If no one has any problems with my suggestions, and the current maintainer of the installer is willing to consider my patches, I'll start work on this.
I'd really like single-feature patches (diff -u), but it sounds like you are heading off down a "rewrite everything" road. In that situation, I'll probably not consider large patches and just wait until you have a working alternative.
The separation of installation and configuration lends itself to a small patch... as does configuring the installer to accept pre-assigned MySQL accounts. Shall I start with those two, then we can consider the other two, and I'll try to think of ways to deal with the passwords and the post-installation configuration of Koha? Thanks. -- Jared Camins-Esakov -- Jared Camins-Esakov E-mail: camins2@tcnj.edu