At 10:33 AM 2/6/2001, Gavin Scott wrote:
>Frank writes:
> > Donna pointed out some of the advantages of the Java release strategy.  Is
> > it possible for you, Mike Yawn, etal. to create, where possible, an
> > evolving standard release strategy ?  I work with attorneys so
> > how 'bout ... to include but not be limited to standard naming conventions,
> > directory structure, and otherwise general philosophy.  Keeping things as
> > simple as possible makes the 3000 more accessible to those we would hope to
> > attract to the platform.
>
>Those of us involved with the Gnu tools distributions would be interested in
>participating in such an activity.
>
>Many of us on 3000-L have experimented with probably every distribution
>mechanism ever invented for software on the 3000 snd still not yet found one
>which solves all the problems:
>
>* Universally applicable
>
>   The ideal distribution mechnaism should be useable by all 3000 users
>   or at least those with some minimal set of requirements such as being
>   on a supported MPE release and having the ability to get a file from
>   the Internet to the 3000 somehow.
>
>   An installation tool which requires access to the internet directly
>   from the 3000 would not be universally applicable because not everyone
>   has their 3000 set up to access the internet.
>
>* Easy to use
>
>   Many of the current mechanisms require the user to jump through too many
>   hoops in getting a downloaded file up to the 3000 in the right form.  In
>   many ways this is a reflection of the previous requirement, and the
>   problems with the different PC->3000 upload options, and the need by some
>   tools for bytestream versus fixed length files, etc.
>
>* Versioning issues
>
>   Like Java, it should be possible to install mutiple versions of a package
>   on the system at once, to easily switch between versions, and to easily
>   remove unwanted versions.
>
>* Splitting of /usr and /var
>
>   To use the Unix terminology, the static parts of the application should
>   be kept apart from the "variable" or configuration part of the package.
>
>   It should be possible to install a version over itself repeatedly
>   without wiping out configuration files, etc.
>
>* Standardized invocation
>
>   There should be a standard mechanism for arranging for the "entrypoint"
>   executables that people use to invoke the package to be located in a
>   common location, and/or a way to augment the system $PATH to include
>   the new package (taking into account the versioning issues above).
>
>I could go on, but these are the most important things that come to mind
>quickly.  There are a lot of other little things such as being able to
>validate that a package is installed completely and the files are
>uncorrupted, etc.
>
>Many of these issues have been addressed by the various package managers use
>under Linux and similar OSes (the Redhat Package Manager RPM, etc.), so
>investigating whether it might be possible to port and enhance one of these
>tools to MPE would be one possible course of action.

Speaking as a Linux software company, the RPM and DEB package formats are
an absolute nightmare.  They are different from distribution to
distribution and from release to release.  So a Mandrake 7.2 RPM is not the
same as a RedHat 6.2 RPM which is not the same as a RedHat 7.0 RPM,
etc.  Then if you've installed software by compiling it, it won't be in the
RPM database.  There is a large number of efforts working to find a more
sane system on Linux, please please do not port or use this method on the 3000.

>I think it would be worth it to the community to expend some effort on this
>problem, since the last thing we need is more "halfway" solutions which add
>new combinations of problems for each package that exists (not meaning to
>imply that there's anything wrong with Mark's new stuff at all).
>
>Actually creating a single "universal" distribution tool that is reliable,
>fail-safe, extensible, and so forth would be a huge win for the entire
>HPe3000 community.
>
>And I don't think that the solution has to be all that complicated to
>implement either.  A few well constructed conventions plus a standard
>download and transfer to the 3000 procedure might be all that are really
>required.
>
>G.


Regards,

Shawn Gordon
President
theKompany.com
www.thekompany.com
949-713-3276