I just had the occasion to install Ikonboard (http://www.ikonboard.com/) a piece of message board software written in Perl. It was an enlightening experience, and one I'd like to share. There's been some discussion previously about the problem with installing OpenGuides being that the build process installs both the modules and the site. I think the Ikonboard guys have hit the nail on the head with their install process, so here's a breakdown of how it works. * You untar the install package and move the contents of the cgi-bin directory to wherever your CGIs live. There's a perl_test.cgi and an installer.cgi which you chmod +x. * Running perl_test.cgi from your browser checks whether you have prerequisite modules (CGI, DBI_File at least, or optimally various DBI drivers) installed, and prints out both a bunch of $ENV and the contents of your @INC for you to keep around for debugging purposes should you need it. * If you have everything, next you run installer.cgi from your browser. You're presented with a screen that lists various files (such as the ikonboard.conf file) and directories and whether they have their permissions set correctly for the install to proceed. If they're not, you set them appropriately and re-run the script. Presuming everything is correct, it presents you with a button to proceed. * Next you get a screen with various fields where you set paths to the various directories - skins, static HTML, uploads, and so on. * The next screen checks permissions on all these places as being writable. * Next, the installer untars a bunch of tarballs that were included in the installation directory, and moves their contents to the directories you specified. One screen appears per untar; if successful, it reloads the script with an incremented CGI argument to move on to the next file. Very smooth to watch. Presumably if anything fails it presents an error screen. (Note: this whole step is optional; you can choose to skip it if you've already manually placed various files in their destinations.) * Next you get a screen to choose your admin user name and password, set the name of the site and board to be displayed, and so on, and asks you what kind of DB you want. * The next step sets up the database and displays a confirmation of the stuff that just happened. * Finally, it redirects you to the board login screen - but the board script refuses to run until you've gotten rid of installer.cgi, as that would be a security hole. After you've ditched it, you can log in. Overall, it's an excellent install experience. Hopefully you can see how well it maps onto the site-related part of our own install mechanism. I can see our existing Build.PL being hacked into two parts - the first part, which remains Build.PL, installs the libraries. The second part would become our installer.cgi. I see their reason for keeping perl_test.cgi separate, as well: if a user is having problems, they can run it to produce an instant system report to diagnose issues. As a minor note, I think having the various templates and so on as tar files within the tar file may be slight overkill - copying from one dir to another works for me. If people like the sound of this (perhaps even try downloading and running the thing yourself; it only takes a moment and you can throw away the result), would you be interested in me having a go at producing something like it for us? My only slight reservation about this is that I don't know how Dom's packaging for Debian works, and if this would be completely incompatible with it. Dom? Cheers, Earle. -- Earle Martin http://downlode.org/ http://purl.org/net/earlemartin/