[Info-vax] OpenVMS development tooling (was: Re: VSI strategy for OpenVMS)

[Stephen Hoffman]

On 2021-09-27 10:19:25 +0000, chris said:

> On 09/27/21 02:01, Lawrence D’Oliveiro wrote:
>> On Monday, September 27, 2021 at 5:17:31 AM UTC+13, chris wrote:
>>> Not uncommon to have /usr/lib full of various revisions of the same library.
>> 
>> Everything in /usr/lib (and /usr/bin, and /usr/share, and all the rest 
>> of it) belongs to an installed package. If that package was 
>> auto-installed, then it was brought in as a dependency of another 
>> package. Ultimately you can trace the dependency chain back to 
>> something that the user explicitly asked for. Maybe they later change 
>> their mind, and don’t want it. So you have “apt-get autoremove”, which 
>> will clean up everything that is not (directly or indirectly) a 
>> dependency of such an explicit installation. Thus, everything stays 
>> clean and tidy.
>> 
>> And all the tools for managing this are part of the distro itself. 
>> After all, the distro maintainers themselves use the same tools.
> 
> It's not a criticism. They have had years to fine tune and get it 
> right. Spent some time while back building packages for FreeBSD Sparc 
> and the build process is smart enough to know which other packages need 
> to be pulled in and built as well. In one case, Xvnc, ended up pulling 
> in around 50 other packages before finally building Xvnc. Very 
> impressive indeed...

That's typical in the other areas I'm working with. macOS has the 
open-source project homebrew, which pulls in some fairly complex 
recipes with many dependencies, and it typically all just builds. (Into 
/usr/local, as the /usr/bin, /usr/sbin, and related areas are now 
protected against access.) Lots of options for package managers around 
on various platforms, too. Some good, some bad.

OpenVMS tooling in this area is weak.

I'm perpetually struggling with PCSI.  It works for what DEC designed 
it for, thankfully the corruptions are much more rare, and support for 
limited rollbacks aside. Chunks of the PCSI database support ties back 
to gaps in database support on OpenVMS—that mess is underneath a number 
of other messes in app code.

If you decide to keep your app files outside of SYS$SYSROOT and/or off 
of SYS$SYSDEVICE:, PCSI becomes little better than a wrapper around 
increasingly-ginormous and fragile user-written DCL procedures.

Building the PCSI kit files is tedious, and most of us end up writing a 
tool which generates the PCSI files, where we have a changing 
collection of files that need to be installed. Multi-architecture 
support in PCSI gets get interesting too, though—with the official end 
of Alpha and Itanium versions—that will be of decreasing interest until 
the VSI OpenVMS Armv9 or Armv10 ports arrive.

Due to the effort involved, I've been seriously tempted to use 
VMSINSTAL in preference to PCSI, and ignore the extras that PCSI 
provides. Reverting is such sweet sorrow.

DECset MMS just isn't worth using for app builds. DECset MMS and much 
of the rest of DECset was pretty good for its time, but has been 
ignored for far too long. In that area, MMK has been less buggy than 
MMS. VSI will hopefully be releasing a viable CMake as part of the LLVM 
work. Yes, I'm interested in Visual Studio Code / VSI IDE here too, but 
it's early yet and the VSI IDE integration with OpenVMS is a little 
lacking. Getting it to install and work needs to be closer to 
installing DECset LSEDIT.

Installations have to create their own compatibility implementations 
either within the apps, or in the installers or posting some doc and 
pushing the problem into the apps, everybody does it differently, and 
the current HPE and VSI SSL multi-version compatibility... missed, and 
the mixed-version clustering support also... missed. This same pattern 
repeats. Clustering. The previous SSL V1.3-to-V1.4 mess, too. That old 
and broken APIs can't be gotten rid of ties in here, too. Things here 
have gotten bad enough here that system use of the GSMATCH mechanism 
was silently disabled within the RTLs a while back.

Updates and update notifications are a problem, too. Too many outdated 
app and tool and OpenVMS versions in use in too many places.  How the 
recently-teased tool VSP fits into any this, and whether VSP is tied 
into PCSI? VSI Support Portal?

And around abstracting apps using SSL/TLS and IPv6 and DNS and the rest 
from the changes that have and will continue in these areas, OpenVMS 
ignores.

And support for isolating apps from other apps is unavailable, whether 
for simple collisions of UICs (what a mess UICs have become) or 
usernames or any of the system-wide constructs, or to isolate the 
damage that can arise from app breaches.  There's no means to just get 
a username with a unique UIC, as a specific instance. And yes, I've met 
both UIC and username collisions, and if I want multiple versions of 
some app or service (see above) to install, now I have to manage those 
UICs and usernames and the rest myself.

I'd like to get these installs and multi-version and app isolation and 
the rest to work much more transparently, but far too often the only 
real option here is a pile of documentation that can then get ignored 
or incompletely followed, and with hopefully enough error checking 
present, and calls to support. Tossing these problems on the end-user 
is a cost-shift and a way to increase costs both for the vendor and for 
the end user. It's an approach that just isn't viable, but it is what 
it is.

Which all reminds me of another longstanding missing dependency that I 
need to check for, whether zip and unzip are in V9.1...

Ah, well. Back to work.



Some related reading:
https://nixos.org/guides/how-nix-works.html
https://wiki.archlinux.org/title/Pacman
https://brew.sh



-- 
Pure Personal Opinion | HoffmanLabs LLC