Hi, On 12/13/07, MJ Ray <[EMAIL PROTECTED]> wrote: > "Galen Charlton" <[EMAIL PROTECTED]> wrote: > > * Prompting for more configuration information during perl Makefile.PL > > Has this been done in a way that makes this step difficult to > automate/package? It looks very similar to repeating some mistakes of > the 2.2 installer. I think any questions should be asked by a very > simple front-end script that sets variables and then calls a silent > Makefile.PL. That would also probably make it easier for GUI > installer makers to see what they needed to do.
All parameters can now be set by using environment variables and running perl Makefie.PL either detached from STDIN or by setting PERL_MM_USE_DEFAULT -- see more below. > Can _get_value() get stuck in an infinite loop if the supplied > $default isn't in $valid_values and STDIN is empty (so prompt returns > $default every time)? OK, it should never happen, but I'd bet it will... Shouldn't happen (and didn't when I tested it): per EU::MM documentation, prompt() detects when it is being run non-interactively and automatically supplies the default value. It also supplies the default value when he PERL_MM_USE_DEFAULT environment variable is set to (Perl) true. > > * Files are now installed with u+w. > > Is this problematic for suexec users? (I don't know and haven't > tested it yet.) According to my reading of Apache suexec guide, u+w is not a problem (g+w or o+w are, but the installer does not install any files with those modes). That said, I have not done any testing using suexec mode, and would appreciate information from anybody who has. > > As a consequence, this means that by default use of the PERL5LIB > > environment variable is necessary; 'make install' now prints a message > > suggesting the the user set KOHA_CONF and PERL5LIB in their profile. > > The default koha-httpd.conf now includes both of these variables. > > > > My main reason for doing this by default is that the C4 modules have > > at present no independent use outside of supporting Koha's CGI scripts > > and are intimately tied to the version of those scripts. Putting them > > in the default @INC will risk problems for users who need to run > > multiple versions of Koha on a box. > > > > Requiring use of PERL5LIB is not perfect, but it should be noted that > > we already have one required environment variable in the form of > > KOHA_CONF. > > Only if the config file isn't in the default location in C4::Context, > surely? The default location (/etc/koha.xml) was wrong and has been for a while; my tree now has the default as /etc/koha/koha-conf.xml. Installation in 'standard' and 'single' mode now also uses rewrite-config.PL to paste in the installed location of koha-conf.xml; in that case, C4::Context now uses the following search hierarchy: 1. File name explicitly passed by use C4::Context /path/to/conf. 2. Value of environment variable KOHA_CONF. 3. Installed file name. 4. Last-ditch default of /etc/koha/koha-conf.xml. When installing in developer mode, you will have to set KOHA_CONF. > To be clear, I think this is a step backwards. My goal is for someone > running one koha on their own server to be able to install it with the > defaults and it to work immediately. I don't think running multiple > versions of Koha on a box is a common requirement except when > upgrading and I think people would be happy to mess with PERL5LIB in > that situation. I agree that a default installation should result in a "just works" setup of Koha. I disagree that running multiple Koha instances is an uncommon requirement: there are a lot of library consortia and service providers who will need to do exactly that. Even a single library who (responsibly) wants to maintain a production instance and one or more test instances will often need or want to use the same box. Therefore, I'm not in favor of putting C4 in Perl's built-in @INC by default However, I am working on a way to make command-line scripts pick up the correct library even if the user does not set PERL5LIB, and hope to post about it tomorrow. > > Related to this, I think it will be useful to consider specifying the > > version number when doing 'use C4::*' from the scripts, and possibly > > consider use of the 'only' pragma [1]. > > Yes, I think that would be a very good idea and one way to guard > against accidents if the API changes. This raises the issue of Koha's main software version number. At present, it ostensibly lives in both kohaversion.pl (used by internal version checking code) and C4/Context.pm (solely for use by Makefile.PL). That's one place too many, so I've edited kohaversion.pl so that it can be used by WriteMakefile()'s VERSION_FROM. Regards, Galen -- Galen Charlton Koha Application Developer LibLime [EMAIL PROTECTED] p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/koha-devel