[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