Item1177: configure doesn't install dependencies

• from Foswiki-1.0.3.tgz
• Also, note that i removed the -T from configure because i got a "Insecure dependency in open while running with -T switch at /usr/lib/perl/5.8/IO/File.pm line 70." error (debian 4.0)

configure.html: configure.html

-- WillNorris - 02 Mar 2009

While fixing this, I re-discovered a very old bug that got introduced by distro:caa811542639, preventing people to install some dependencies.

I'm surprised this doesn't bite us more often, and I'm afraid I can't fix it. We've already discussed this ages ago with OliverKrueger, Crawford and Will, but...

Anyway, the root cause of the current bug was that Foswiki CPAN libraries aren't available from within extender.pl, which wasn't very obvious to me.

Therefore, I've fixed setlib.cfg so it should be more reliable, and it should resolve $foswikiLibPath more acurately. Otherwise, extender.pl, which requires UNIVERSAL::require, will fail, unless this module is installed in the system.

Because of the other bug, it's hard to tell whether this is entirely fixed or not, but at least the root cause is, so one can safely depend on CPAN from extender.pl. As a side-effect, we now can safely use CPAN modules directly from Foswiki core, which we couldn't before (as extender.pl do a Foswiki->new to get a session).

-- OlivierRaginel - 03 Mar 2009

radically different behavior now:

Software error:

Failed to load the perl module Foswiki::Configure::Checker. The module could not be found. 

Please ensure that:
   1 Foswiki::Configure::Checker is installed,
   2 that the module is available on the @INC path,
   3 that the webserver user (www-data) has permission to read the Foswiki/Configure/Checker.pm file.
The detailed error seen was:
Can't locate Foswiki/Configure/Checker.pm in @INC (@INC contains: /lib . /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl) at (eval 17) line 2.
BEGIN failed--compilation aborted at (eval 17) line 2.

-- WillNorris - 03 Mar 2009

ah, with a bin/LocalLib.cfg file, configure runs.

Content-Length: 408
Status: 400
Content-Type: text/html; charset=ISO-8859-1

Bad Request

Bad request (malformed multipart POST)

Error: Installer returned errors:

Can't call method "use" without a package or object reference at /var/www/mnemosyne.biohack.net/foswiki/tools/extender.pl line 854.

-- WillNorris - 03 Mar 2009

Got it. Most DEPENDENCIES files use >=1.3 or >0, not just the number, which doesn't fit with the ->VERSION call.

As for the taint mode, check Item1197 (thanks Kenneth for opening this one up)

Most of this should be fixed now. Only problem left is these strange return codes, but I couldn't find where they are coming from, and it doesn't seem to prevent the installation from being successful.

Will, thanks to report now on how it goes with the latest code from the release branch.

-- OlivierRaginel - 04 Mar 2009

I have seen these "bad request" messages recently too. They are new, and need to be investigated!

-- CrawfordCurrie - 05 Mar 2009

Congraultions, the dependencies are detected and installed! (thought the "BAD REQUESTS" do make me think something has failed, but in fact, everything does install successfully).

attached configure-install-dependencies.html is the output.

-- WillNorris - 05 Mar 2009

Without a LocalLib.cfg, it fails because of an extra / I put Re-opening to fix.

-- OlivierRaginel - 06 Mar 2009

Damned... The problem with ->VERSION makes configure re-install already installed extensions, such as JSCalendarContrib, which have their VERSION set to something.

Therefore, making extender.pl more clever. If version is rejected, then extract number from revision, and use that.

By doing that, I found out that we were re-installing plugins such as JSCalendarContrib. After fixing the script so that it won't re-install the same plugins, the Bad request error message disappeared. It might be related to re-installing the JSCalenderContrib. If you manage to trigger the Bad request error message again, please open a new bug report and assign it to me.

-- OlivierRaginel - 09 Mar 2009

I hope it's the last bug... I'm relying on a warning being generated for version strings not "perl-like", but this warning isn't generated by default in perl < 5.10. Therefore, I have to force the version evaluation, and all should be well.

-- OlivierRaginel - 11 Mar 2009