[Info-vax] OpenVMS development tooling

[^P]

On Tuesday, September 28, 2021 at 1:41:28 AM UTC+2, chris wrote:
> On 09/27/21 22:57, ^P wrote: 
> > 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
> We wish. I wouldn't inflict X86 architecture on my worst enemy, assuming 
> I had one... 
> 
> Chris

VSI mentions, in roadmap for time after 2022, it depends on market trends and customers, maybe a RISC-V is trending then?

^P