[Info-vax] OpenVMS development tooling

[chris]

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