[Info-vax] Updates to VMSTAR and Wget for VMS

[Arne Vajhøj]

On 1/4/2021 1:32 PM, Hunter Goatley wrote:
> On 1/4/2021 8:24 AM, Phillip Helbig (undress to reply) wrote
>> I don't know if it's worth the trouble, but it would be nice if
>> third-party software like this had some sort of standard setup, i.e. a
>> ZIP file would create a directory with the product name and version
>> number and unpack the files in it, then @[.DIR]BUILD would build it
>> (probably calling @COMPILE and @LINK) and @[.DIR]SETUP (possibly also
>> called from BUILD) would set it up initially (say buy adding the .HLB to
>> a library specified by a logical name or, if empty, prompt for it (NOT
>> add it to VMS HELP by default)) and then  @[.DIR]INSTALL would be done
>> at boot for installing images, setting up DCL verbs, or whatever, and
>> @[.DIR]DEFINE would be invoked before using it, probably usually
>> indirectly via SYS$SYLOGIN or LOGIN.COM, in order to define a symbol or
>> whatever.  One could then build a list of directories on the disk
>> (perhaps a concealed device) where such packages are on the fly at boot
>> to call all the INSTALL procedures and at login to call all the DEFINE
>> procedures.

That is actually very interesting idea.

The standard for VMS open source packaging.

> Some of the .zip files in my archive (all of the ones I worked on or 
> repackaged) have a LINK.COM to create .EXE files from the supplied 
> binaries. I never had the time to go through all of packages and try to 
> do what you're describing.

It should probably fall on the maintainers of the open source not
the distribution host.

> I had once thought of trying to create VMSINSTAL kits for everything, 
> but that was way too much work and would take way too much time for the 
> free time I've ever had.

I don't think VMSINSTAL is the right solution.

I believe it should work for no priv users and
be strictly isolated to the dir where it is unpacked.

Arne