[Info-vax] Looking to find a way to pull all the Open Source / Freeware folks together

[Phillip Helbig---remove CLOTHES to reply]

In article
<15a1d274-f192-4e5d-967d-50738106d693 at m11g2000yqf.googlegroups.com>,
Steven Schweda <sms.antinode at gmail.com> writes: 

> > We need a one-stop shop.  [...]
> 
>    I'm not convinced.  A one-stop directory is fine, but I
> like to serve my own stuff, so I can see what gets downloaded.

I don't see the two as mutually exclusive.

Imagine a list like on Hunter's server.  One could have the packages 
there and/or a link to the main site of that package and/or directly to the 
package on the main site.  It's certainly good that ZIP, LYNX etc have 
their own sites.  If one is interested in beta versions, historical 
versions, discussion, development etc it is really essential.  But IN 
ADDITION there could be a one-stop shop.  The advantage is a) there is 
only one site to check to see if there is anything new and b) it keeps 
the packages available even after their main sites no longer exist, are 
not maintained etc.  I'm assuming that people would upload the latest 
stable version to the one-stop shop.

A one-stop shop could also provide some stuff which the main sites
cannot or don't want to, such as executables and/or object files built
on different versions of VMS etc.

> There's a near-one-stop server for HP-UX stuff, of which
> there's more than there would be for VMS, and it often runs
> behind the current versions of things.  I'd expect the
> workload involved in maintaining such a one-stop server to be
> fairly high.  

Best, of course, would be if the developers upload the latest stable 
versions.  But if not, the maintainer could periodically check for new 
stuff and of course other people could send him notifications when 
something new exists.


> > Come up with a unified scheme for packaging and building.
> 
>    Good luck.

PCSI and VMSINSTAL exist, of course, but I think they are overkill for 
most things, many of which are just an executable and a symbol to point 
to it.  A DCL procedure is self-documenting (or should be) to those who 
want to look inside.

> >   I suggest ZIP
> > for packaging.  Some questions: should UNZIP then create a subdirectory
> > where the stuff goes, or should it be unpacked where the ZIP file is
> > (but, of course, perhaps with subdirectories)?
> 
>    With the possible exception of a one-file product, no
> product should ever put more than a directory into the current
> directory when it's unpacked.  Cleaning up the mess after
> unpacking some large kit in the wrong place is normally
> enough to persuade anyone of this.

I agree.

> >   How should executables
> > and object files be named to differentiate between architectures?  How
> > is the package built?
> 
>    I've adopted separate directories for product files for
> different architectures.  I like that scheme.  Others like
> different file types.  Good luck getting universal agreement.

Different directories is more VMS-like: all executables are called .EXE 
and different architectures are naturally in different directories (on 
different disks).

> > HELP files, such as those with ZIP and UNZIP, should be
> > required.
> 
>    What's the penalty for not doing what's "required".  (I'll
> pay it.)

Your HELP files are great!

There would be no penalty.  However, a product which conforms to the 
guidelines would be preferred by users who know exactly what they are 
getting; they don't have to worry about some procedure putting stuff on 
the system disk, inserting stuff into the main HELP library at the wrong 
level, installing images etc.

> > Reference: Should the user define symbols, logical names etc as
> > described in the documentation, or should each package have procedures
> > to be executed a) at startup and b) from SYS$SYLOGIN or wherever to set
> > things up in a way which is guaranteed not to clash with anything else?
> 
>    I prefer to leave that stuff to the user.  Others seem to
> prefer complete PCSI kits.  Good luck getting universal
> agreement.

I think a setup procedure, such as NEWSRDR has, is good middle ground.  
The user is free not to use it.

> > I think the procedure is the way to go.  [...]
> 
>    Oh, yeah.  As if I'm likely to plop some other moron's DCL
> into my SYS$SYLOGIN.  (My own is bad enough.)

No, I mean something like 

   $ @ DISK$SOFT:[PACKAGE]PACKAGE_SETUP.COM

The user, system manager etc could have a line like this for each 
package.  One probably needs two such collections of commands, one 
executed at startup and one executed at login.