delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/03/20/12:25:07

From: "Tim Bird" <tbird AT caldera DOT com>
Message-Id: <9703201019.ZM16594@caldera.com>
Date: Thu, 20 Mar 1997 10:19:03 -0700
In-Reply-To: "Mike A. Harris" <mharris@blackwidow.saultc.on.ca>
"Re: [opendos] FSSTND" (Mar 20, 4:54am)
References: <Pine DOT LNX DOT 3 DOT 95 DOT 970320043358 DOT 12128w-100000 AT capslock DOT com>
To: opendos AT mail DOT tacoma DOT net
Subject: Re: [opendos] FSSTND
Mime-Version: 1.0

Mike A. Harris wrote:
> Well, not really compatibility per-se, but more like this.
> A user installs a program into the standard directory, then the
> install is logged in some way by the as yet to be decided OpenDOS
> "smart installer" then when you want to uninstall, you just run
> the OD uninstaller, and you're done with it.  If you decide to
> not use the standard, then you're stuck uninstalling the stuff
> yourself as is now the case.  Either way, you still can do
> whatever you want, either abiding by the OPTIONAL standard or
> not.  New "smart installer" aware programs would make the install
> process easier, also, they would install in the conventional way
> if no smart installer was present.
[...]
> If we are going to try and make such a standard at all, we've got
> to either make something USEFUL or nothing at all.  When I talk
> about these standards, I'm not talking about an "install
> standard"  I'm talking about a "filesystem standard".   This
> standard NAMES the standard directories where things will be
> installed, etc.  It is just a RECOMMENDATION however and nothing
> more.  What others are saying isn't such a standard at all but
> more of a smart install program with no real standard at all.
>
> Needless to say, either type of thing would be better than what
> we've got, however a filesystem standard would be the superior
> approach.  If such a standard were created, then over time most
> OpenDOS computers directory structures would look very much the
> same and anyone could jump from machine to machine in DOS very
> easy way without trying to do a filefind or a DIR /S, etc...
>
> Again, since the standard would ONLY BE A RECOMMENDATION, other
> users would NOT have to abide by it anyways.  Those who did
> however would benefit greatly by the features of the standard.

Mike has hit the nail on the head here.  If this is on the wishlist,
it should be separated into 2 parts: a file system standard, and
a "smart installer" facility.  Both would be applicable not only
to OpenDOS, but also to MSDOS systems.  The smart installer could
come with OpenDOS and/or be freely available for use by the original
program creators, and would function as described above.  That is,
the smart installer (usually referred to as a "package manager" on other
OSes) would perform a "smarter" install on a system where certain
configuration files were present, otherwise it would ask where to put
things.  In either case, it should remember where things are, allow
queries about file integrity and modifications, and also allow easy
upgrade or removal of packages.  The redhat package manager (rpm)
handles all of these - but I'm not sure if a straight port would be
appropriate.  We'd probably want to use pkzip or another DOS-ish
archive format, as well as convert other parts to function in a
way more relevant to DOS' peculiarities.

I have a game company, and we had to write our own install program.
There's no competitive advantage in having our own install, and we
would have been just as happy to take an off-the-shelf one.  There's
probably a good one that's freely available that I missed finding
on the net.  If a "smart" one was available, then I think many
developers would use it.  Also, you could package existing .ZIP files
with it.

Since the hardest thing to do to get a project off the ground is come
up with the name, I'll suggest one: The OpenDOS Package Manager
(OPM for short)  Hopefully no one will misunderstand when
someone says "I really need OPM!" :^)

Tim Bird

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019