[Info-vax] VMS and package managers, was: Re: Micro Focus Merger with Hewlett Packard Enterprise's Software Business Segment

[Stephen Hoffman]

On 2016-10-04 05:57:23 +0000, John E. Malmberg said:

> On 10/3/2016 7:57 PM, Simon Clubley wrote:
>> 
>> Absolutely no reason why not; the licence would just be an additional 
>> optional step.
>> 
>> A package would also record _all_ the quotas/resources/system 
>> configuration information it needs within the installation file itself 
>> and a VMS package manager could also automatically apply these as 
>> required. When deinstalling the package, the package manager could then 
>> optionally reverse these changes (where it either made any sense to do 
>> so or was otherwise viable to do so of course).
> 
> PCSI can record this information, all that is is data in the file.
> 
> Autogen has the ability to automatically use such files installed by 
> the package.  Some packages take advantage of this.

For as far as that goes.    This is the bits-n-pieces "design" that 
OpenVMS has been following for far too long.   Lots of bits around the 
edges, never particularly integrated, and certainly not encouraged or 
required, and lacking in certain areas such as the use of an actual 
database underneath the tool and not the usual home-grown RMS mess, the 
difficulties around resetting parameters, and the morass around startup 
ordering and startup removal.   The lack of notifications, the lack of 
integrated downloads, and other details.   PCSI can certainly be 
improved.  It'd e nice to have features that eliminate the need for the 
DCL kitting wrappers many of us have; wrappers that scan the kitting 
directories for files and generates the PCSI kit, for instance.   
Fixing and simplifying the multi-architecture kitting bugs that were 
recently discussed, too.

>> You could also supply a list of users using a package and have their 
>> user quotas increased automatically by the package manager instead of 
>> you having to do it manually. You could do this either during 
>> installation or ask the package manager to configure additional 
>> usernames afterwards as needed.
> 
> Usually packages can not set fixed quotas, but can install scripts to 
> be run at login to validate the quotas.  Several DECSET packages do 
> this.

I and others have written tools that scan the authorize file to raise 
the quotas to specified minimums.   That's a fairly common task for 
folks, and helps with the stability and reliability and maintainability 
of the packages.   This case also arises well after install time, too.  
 Same for verifying system parameters, for that matter.   That too 
needs to happen at boot or at product startup.   Every time.

>> If VMS had some kind of decent init system for startup, such a package 
>> manager could then automatically insert the package into the startup 
>> sequence (and at the correct point) if required and then remove it 
>> automatically during product removal.
> 
> I do not know what your definition of decent is.  The sysman utility 
> can update that startup database:
> 
>    mcr sysman help startup

The SYSMAN approach — as current implemented — works well for simple 
cases, but fell flat back at the initial release back at VAX/VMS V5.0, 
and the integration with PCSI and VMSINSTAL was downplayed because of 
the gaps in the SYSMAN STARTUP design.   The current design fails to 
deal well with startup ordering in non-trivial environments; with the 
dependency and sequencing management that arises in environments with 
arbitrary software installations.

>> Such a package manager would also have tools to let you know when 
>> updated versions of your packages are available (for example, when a 
>> new patch is available) and allow you to download the updated package 
>> over a verifiably trustable connection and then install it.
>> 
>> There are also various other things you can do with a package manager; 
>> looking at the man pages for the various Linux package managers will 
>> give you some insights.
>> 
>> IOW, yes VMS needs a package manager (and a decent init system) and yes 
>> all that manual stuff you do when installing some tools should not be 
>> needed in the 21st century.
>> 
>> Simon.
>> 
>> PS: PCSI does not count as a package manager and systartup_vms.com and 
>> friends do not count as a decent init system. If you think they do, 
>> then you have never used a real package manager or init system. (IMHO).
> 
> Yes, PCSI is a package installer/remover, not a package manager.  It 
> could probably be quite a bit improved.

No need for "could", there.

> I have not used the sysman startup features in the PCSI kits.
> 
> A package manager could be implemented that knew how to use 
> PCSI/VMSINSTAL to install things.

Ayup.   More than enough room.   But then this is all headed toward 
container management and sandboxing and jails, toward actual job 
scheduling and distributed process control, device management and other 
details. Toward Docker (or maybe akin to OCI 
https://www.opencontainers.org — and OCI might well be available and 
stable by the time VSI is looking around) and maybe with Kubernetes or 
such, and with DECscheduler or analogous for distributed scheduling, 
and other pieces.  Device management would be nice, as we're headed 
toward an install asking for some disk units and having the storage 
system instantiate all that from some pool of blocks.   Moving to 
containers for the apps avoids various of the morasses such as with the 
DEC C logical name mess, and around startups and such details — you're 
virtualizing an OpenVMS interface to the applications, rather than 
virtualizing the Integrity or Alpha or x86 hardware interface — and 
helps keep unrelated apps from even accessing each other.


-- 
Pure Personal Opinion | HoffmanLabs LLC