On Tue, 15 Jul 2014 09:57:42 +0200 "john.d...@compinia.de" <john.d...@compinia.de> wrote:
>> Using a PCSI kit also has problems if you want to install Perl onto a >> cluster-common disk, which is not the boot disk, because you end up with >> PRODUCT SHOW PRODUCT listing the kit on one machine but not on the >> other(s). >> >> The kit itself is just a complete directory tree so perhaps a PRODUCT >> EXTRACT command would do the trick instead? >> >Of course that is one approach, but seeing that someone has gone to all >the trouble of 'packetizing' perl it is a shame. >Surely in the 'open source' space one is never sure whether one's open >source based application is going to work with a new version of, in this >case perl, especially if one has compiled additional modules. So it >would make sense, to let you switch environments, from old to new and >back again. The way the PCSI works for perl at the moment, has become a >nugatory activity. > >Kind regards >John > ANY new environment should (imho) support code and programs develloped in an older environment. It's called backward compatbility (IIRC) and this is indeed a concept that is missing in many 'modern' environments - mainly *X based, and not necessarily open-source (remember older versions of java?) or non-VMS (rememner SWS (AKA Apache?)). In some projects, there now is a fairly good awareness of the need, in many projects, though not always possible (OpenSSL 1.0 s. 0.9.8).... It is also common to install software of a predefined location - especially in the Linux world. The name _may_ include a version indication, in which case you will need ta adapt your references, eventually rebuild your software alltogether. Worst case however, it will be the same location as the previous version - like PCSI. Or even - as I have encountered - there is no choice than to use this 'default' location. Using open-source that installes this way, I have run into severe trouble bacause the new version was not usable at all (it actually ruined the database). The remedy is simple: Install default, rename the rootdirectory to include the version and adapt all code that refers to the environment to match this new name. Switching between versions is now easy by defining a one of just a few logicals. But the best solution is - as always - to PREVENT this from happening. PCSI is fine for software that is REALLY backward compatible, or is at the base of the system. Otherwise, use other methods; for example delivering object files and all procedures and files needed to link them together locally - LINK is included in teh OpenVMS system. (the WASD webserver is distributed that way). Willem
