more install.sh

[David Lee]

On Tue, 21 Oct 2008, Julian Field wrote:

> Mark Nienberg wrote:
>> I think on a centOS system the installer.sh is doing this for the perl 
>> modules that conflict with the base perl:
>> 
>> check to see if the perl module is installed,
>> see that it isn't,
>> build an rpm for the module from the downloaded src,
>> attempt to install the rpm, but the install fails due to conflict with 
>> installed perl,
>> force install only for those that absolutely need it.
>> 
>> I'm wondering if the process could be shorted to eliminate building the rpm 
>> for the module if the rpm already exists in /usr/src/redhat/RPMS (probably 
>> from a previous MailScanner install).
> No, because then if something went wrong with the install (in that a corrupt 
> RPM got built somehow), then re-installing wouldn't help the situation, and 
> you would have to get into all sorts of messing around deleting files to get 
> yourself out of the hole.

Is part (even all?) of the problem that some modules don't offer "VERSION" 
information?  My skim-reading of "install.sh" and "CheckModuleVersion" 
suggests that MS only installs any given module either if its "VERSION" is 
too old, or if it doesn't support "VERSION" at all.  (If a module both has 
"VERSION" and if that version is good enough, then the MS can safely skip 
its installation altogether.)  Is that correct?

If so, might it help if some of us here (not necessarily Julian) tried to 
persuade authors of VERSION-lacking modules to add "VERSION" support?


>> Alternatively, could the initial check for the module be improved somehow 
>> to detect that the module is already installed as part of the the core perl 
>> installation? I suspect that must not be possible or Jules would have done 
>> it already.
> Not easy. You can't find where a Perl module is installed, just that it *is* 
> installed.

... and (if the installed module supports it) its VERSION.


>> Could the installer test for already installed rpms before building and 
>> attempting installation of the new one?
>> In the above example it would run "rpm -q perl-IO-stringy" and then do some 
>> sort of version checking.
> The version checking you need to do is far from trivial. 2.10 is greater than 
> 2.9, but not in numerical or alphabetical terms. It's quite a tricky problem. 
> I really don't want to open that Pandora's box! :-)

But presumably the checking code in "CheckModuleVersion" is OK?  So if a 
currently VERSION-lacking module could be persuaded to support VERSION, 
then things should be improved for that module, shouldn't they?

There will, of course, be time delay for this to become effective until 
such support has trickled into future distributions.

Might such a strategy (admittedly longer-term rather than quick-fix) help?


-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:  UNIX Team Leader                         Durham University     :
:                                           South Road            :
:  http://www.dur.ac.uk/t.d.lee/            Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :