Item10940: LocalSite.cfg supports specifications relative to other definitions, but configure breaks them.

For example, I can define a single $Foswiki::cfg{InstallPath} and then use that in other definitions. It works, but not in confiure. Configure needs to apply $Foswiki::cfg expansion before performing checks.

I consider this to be a bug, because it causes issues with a number of sensible configuration setups.

-- CrawfordCurrie - 05 Jul 2011

This is going to break the CLI version of the Extensions installer. it depends upon at least something in LSC being absolute. If does not have any of the code to load LSC, but parses the paths out of the file. tools/extender.pl needs to be reworked to load or require LSC instead of parsing it.

Not sure how to fix this. The problem is that from the CLI, if the Script directory has been re-mapped, such as to cgi-bin, I'm not sure the best way to find it. It's a bit of a catch-22 because the "right" method would be to run setlib.cfg which is in the bin directory. Apache knows where the bin directory is because that's where it runs configure from, but from the cli, that's not available. [Actually in looking at this a bit further, it's a matter of timing. Need to find bin to run setlib to build env to properly load LCS. So the code parses out the ScriptDir to find setlib, so then everything else can be properly loaded.]

I'd suggest that we deprecate mapping of the bin directory, but that is probably one of the more useful directory renames for sites that require a cgi-bin outside of the web root. In any event, making all this relative makes a hash of this.

-- GeorgeClark - 05 Jul 2011

Also, This fix further breaks the issue that was already reported in Item10240 and is a duplicate of Item10249.

-- GeorgeClark - 05 Jul 2011

Oh - and related to this somewhat is Item10902 - configure should show the user the results of the expansion to make it easier to understand the results of recursive expansions. Anywhere we are going to support a recursive expansion we should also show the fully expanded results.

-- GeorgeClark - 05 Jul 2011

I think this is OK, George. I haven't changed any paths in LSC. I'm not saying you have to use relative paths in LSC, just that with this fix you can use them, and configure will still make a good attempt at it. If the CLI installer is unusable with relative paths, then that more says this fix is incomplete, rather than that it busts something new. I can't see that Item10240 is related, 'cos all my changes have been in the checkers; I didn't touch either LSC or extender.pl. And yes, I added the display of the expansions already (at least for the paths - the same pattern can be used for other settings as appropriate).

Try it, and if you're OK with it, just flick this report back to "WaitingForRelease".

I closed Item10249 which is directly addressed by this change. I'm going to spread it to Release01x01 too.

-- CrawfordCurrie - 06 Jul 2011

I agree, so setting to waiting for release - though making this easier also makes extender breakage more likely. We really need an easy way for cli to find itself. I suspect the harder part is keeping compatibility with the legacy "run the _installer" script, which is hardcoded and distributed widely to run tools/extender.pl

-- GeorgeClark - 06 Jul 2011

Unfortunately this change breaks the startup mode of configure. If you remove the LocalSite.cfg, configure fails with Use of uninitialized value $path in pattern match (m//) at /var/www/foswiki/trunk/core/lib/Foswiki/Configure/Checker.pm line 100. I tried addressing just that failure and it fails elsewhere. Unfortunately I'm not getting any traceback so I can't find out who is calling who. Not sure how to fix this.

-- GeorgeClark - 22 Jul 2011

I think I have this fixed. Committed to release and trunk.

-- GeorgeClark - 23 Jul 2011

Commenting is disabled while not logged in