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

[^P]

On Monday, September 27, 2021 at 5:50:56 PM UTC+2, Stephen Hoffman wrote:
> 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. 

Is this hypothetical or only  a wish? 

^P