[Info-vax] OpenSSL CSWS-2.2-1

Arne Vajhøj arne at vajhoej.dk
Tue Apr 30 19:27:31 EDT 2019


On 4/29/2019 11:01 PM, Craig A. Berry wrote:
> On 4/29/19 8:53 PM, Arne Vajhøj wrote:
>> On 4/29/2019 2:30 PM, Craig A. Berry wrote:
>>> 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.

I would suggest the developer decide what library to link against.

> 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.

That is also fucked up.

/allmyjavaversions/jdk1.8.0_182/bin/java
/allmyjavaversions/jdk-11.0.2/bin/java
etc.

works fine.

And again I want the sysadm to decide what Java version to use.

> 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.

True.

The situation is approx. the same across VMS, Linux and Windows.

Arne




More information about the Info-vax mailing list