[Info-vax] OpenSSL CSWS-2.2-1

[Craig A. Berry]

On 4/29/19 8:53 PM, Arne Vajhøj wrote:
> On 4/29/2019 2:30 PM, Craig A. Berry wrote:
>> On Monday, April 29, 2019 at 12:30:05 PM UTC-5, Simon Clubley wrote:
>>> On 2019-04-29, Craig A. Berry <craig.a.berry at gmail.com> wrote:
>>>> While it will probably throw a wrench into human-readable version
>>>> comparisons for those versions that already exist, v3.x.x might be a 
>>>> good
>>>> time to deal with the fact that in a few years there will likely be an
>>>> OpenSSL 10.x.x.  A product name like SSL0300 for a release based on 
>>>> OpenSSL
>>>> 3.0.x would have an obvious relationship to a product called SSL1013 
>>>> and
>>>> based on OpenSSL 10.13.x.
> 
>>> In fact, all VMS kits based around open source products should just use
>>> the open source product version number as part of the kit name instead
>>> of making up a version number that is VMS specific.
>>>
>>> Having VMS specific version numbers for open source products is just
>>> yet another source of confusion that simply does not need to exist.
> 
>> I agree, but I'm actually talking about product names not version
>> numbers. If you want to simultaneously support two different versions
>> that are not binary compatible with each other, you need different
>> product names and they need to appear not just in the kit names but also
>> in the filenames of whatever libraries end up in sys$share or
>> sys$library, not to mention system-level logical names.
> 
> This is only a problem if products insist on dumping their stuff
> into the operating systems structure.
> 
> Very common across operating systems.
> 
> But still a bad idea in my opinion.

It certainly has its problems, but without a common, canonical location,
configure scripts would not know where to find the library to link
against it.  Of course they then have to examine the headers and see
what version they've got and whether it's compatible with the package
being built.

Having to handle multiple, incompatible versions of the same package is
kind of a mess any way you slice it.  Here's something I recently
encountered on a RHEL system:

$ which java
/usr/bin/java
$ ls -l /usr/bin/java
lrwxrwxrwx 1 root root 22 Apr 22 15:20 /usr/bin/java -> 
/etc/alternatives/java
$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 73 Apr 22 15:20 /etc/alternatives/java -> 
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64/jre/bin/java

So there's double indirection via two symlinks from the canonical
location of the java binary to the actual location.  This system only
has one version of java installed, but if there were more than one, I
could use the "alternatives" program to fiddle with the intermediate
symlink and enable a different version.  Except the installation
processing of a lot of things that depend on Java follows the symlinks
and hard-codes the actual java binary locations in the start-up scripts,
which tends to break something even when you just do a minor update.

Compared to that, choosing between running SYS$STARTUP:SSL$STARTUP or
SYS$STARTUP:SSL1$STARTUP and then following the OPENSSL logical name
doesn't seem especially worse than what everyone else does.