[Tfug] Clean "uninstalls"

[Bexley Hall]

Hi, Jeff,

> Getting a list of the files installed by a package is easy.

Yes.  And, preventing it from putting things in places
that you don't want is also easy -- as long as you
don't let it install as the equivalent of root/eve.

> What the installer and program itself writes to disk are your real
> problems (install scripts that modify config files, data files
> written by the app while it is running, etc).

Exactly.  This is where tagging files (objects) with their
"creator" can pay off -- you can track the "droppings" left
by the application in the course of its execution, etc. 
Of course, you still need some way of letting the user
realize those objects created *intentionally* at his/her
behest vs. those that are "overhead" for the app itself.

> Assuming that the user isn't able to
> modify config files, you should be able to work that out by
> keeping
> the original config file, and then diffs of config files as
> each package is installed.

Well, the user would obviously have to be able to modify
*some* configuration files.  E.g., the configuration files
associated with that application, itself.  So, you need to
be able to isolate those "settings" so that they can be excised
at the time when the app is removed.

> These diffs would be taken against the BASE
> config file, not the updated one.

I don't think this is quite that simple.  :<
E.g., imagine app #2 has modified a configuration for
*something* (for example, possibly tweeked the "master
volume control").  If app #3 can *examine* settings
(instead of just blindly *setting* them), it can decide
that the volume is "correct" -- for its purposes.

Now, when app #2 is backed out and the changes to those
settings that it tweaked are "undone" (e.g., the "master
volume control"), app #3 suddenly is executing with a
different set of settings.

I.e., you have to change the rules for how apps can
examine *and* modify settings so that their independance
is maintained.

> Lets say you install package A, then package B, then
> package C.  Each
> writes to a single config file.  Then, you remove package
> B.  What you
> do is revert back to the original config file, then reapply
> the diffs
> for A & C.  So this would involve keeping track of
> which config files were modified by which apps.

Note the above scenario; C (#3) sees  the configuration
changed to reflect B (#2) when B is present.  But, when
B is removed, C's diffs no longer make sense in the
context of a "removed B".

I think you really have to *enforce* independance in all
settings for which EXPLICIT dependancies are not declared.
I.e., if C consults anything that B could have tweaked,
then B must be declared as a dependancy for C!  Removing
B must cause C to also be removed (since C does not
know how to operate in the absence of B).

To use the volume control example... either allow
B and C to independantly adjust the volume control
(i.e., when B is running, it's output is processed
with volume setting B while C's output is processed
with volume setting C -- i.e., a mixer); or, if the
two are interrelated (e.g., B acting as a preprocessor
for C), then the dependancy has to be explicit.