[Tfug] Clean "uninstalls"

[Bexley Hall]

Hi,

I'm trying to settle on a system philosophy that will
facilitate user's "backing out" software/applications
that they decide they don't want (or, can't "afford").

As always, Windows is the *best* place to start -- because
it usually does things *so* wrong!  :-/

Remember:  I design *appliances* so you're not sitting
looking at a nice big graphic screen with a full QWERTY
keyboard, etc.  Goal is to be able to have a "stock"
product, N different (*possibly* interdependant)
third-party applications and be able to get to a
stable configuration from any other configuration.

So, by way of example:

Start with stock unit, add applications 1, 2 and 6,
remove application 2 and you should be at the same
(exact!) configuration as if you had started with a
stock unit and added 1 and 6 (*or*, 6 and 1).

Note that this isn't always doable even in the
FOSS world!  :<

I *think* a way of doing this is:
- every persistent object created by an application
  is tagged with the identity of that application
- dependencies are implemented dynamically at run
  instead of statically at install time

The first ensures that all files associated with
the application can be identified for eventual
removal.  Note that this applies to the files
associated with the app when it is installed as
well as any "support" files that it might create
as a side-effect of its operation, etc.

E.g., this would be like marking all Excel spreadsheets
created by Excel while it resided on your machine;
but, *not* those spreadsheets that might have resided
on your machine prior to installing Excel; *or*,
those that were installed *after* Excel (as long
as Excel didn't "touch(1)" them).  So, you don't
just naively use the "file extension" to tell you
which objects are associated with Excel (!).

The second ensures that things like .so's are never
discarded or overwritten.  "System" so's are,
obviously, precious.  So, their availability can be
relied upon.  And, if an application "needs" a
particular version of an so, it can only rely on
that so as being available if it declares a
specific dependancy.  (i.e., "This application
relies on application XYZ being present").
Otherwise, it must install its own copy of the
so -- which will be removed when the application
is UNinstalled!

OTOH, you can still gain run-time efficiencies of a
real .so by examining the current .so cache -- if
the required so is currently resident, there's no
need to load *your* copy of it (i.e., if application
A and B each use a particular .so, then they will
each install copies of that so; if application A
is running at the time application B is started,
then application B can use the already loaded
copy of the so).

I suspect I can probably get around the explicit
need for duplicate copies of these so's -- i.e.,
one installed by each application -- using
reference counting but I think Windblows does htat
and it doesnt seem like it has been fool-proof;
perhaps when "installing" the duplicate .so, notice
that it is an EXACT copy of an installed .so and
create a hardlink to the existing copy, instead
(tagging that link with the id of the *new* application
so you know to remove it when/if this app is ever
uninstalled)

The only other issue worth mentioning explicitly
seems to be the "registry" (the registry, imo,
is a great idea, poorly implemented!).  Instead of
a single "database" (misnomer?) with settings for
*all* applications, let each appliation create
it's own "database" of settings -- so that this
database can be clearly identified as "belonging"
to that application.

Have I missed anything?  Is there a simpler model that I
can adopt to get me where I want to be?

Thanks!
--don