[Tfug] Clean "uninstalls"

[Jeffry Johnston]

Getting a list of the files installed by a package is easy.  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).  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.  These diffs would be taken against the BASE
config file, not the updated one.

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.

Jeff



On Wed, Feb 4, 2009 at 7:42 AM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi, Zack,
>
>> > Imagine installing one or more "third party apps" on the
>> > GPS unit in your car.  Now, you decide that app #2 sucks
>> > (or, perhaps you just want to reclaim the resources that it
>> > consumes).  Ideally, you want to be able to remove app #2
>> > in such a way that the resulting system looks like *only*
>> > apps #1 and #3 were (EVER!) installed -- no remnants of
>> > app #2 at all.
>>
>> Ah, like OS X does with application bundles?
>
> Unfamiliar with OSX... each time I get a Mac capable of
> installing OSX I end up having to toss it to make room for
> something else "more interesting"  :-/
>
>> Or various non-linux Unix packaging methods that store the
>> entire installed applications in one directory,
>> which can be easily removed (I'm thinking the /opt
>> directory on Solaris specifically)?
>
> Exactly.  However, note that there is nothing that prevents
> a "third party application" from adhering to this model!  :<
> That seems to be the crux of the problem.
>
> And, in some environments, you really *don't* want to
> confine an application like this.
>
> E.g., imagine an application installing a web interface
> to itself.  It either stuffs this under ~httpd, makes a
> symlink from ~httpd to a place in it's "one directory",
> *or* diddles with the httpd configuration files, etc.
>
> In either case, its tentacles don't neatly reside
> within that "one directory".  Hence my suggestion that
> each *application* be assigned a UID so you could
> just rm everything tagged with that UID to excise
> it from your "device" (appliance).
>
> Of course, this also has problems... :-/
>
> My current thinking is to build a namespace for
> each application.  This has the advantage of also enforcing
> tighter security restraints on "rogue" applications
> (e.g., not allowing the app to get at things that it shouldn't
> *need* to access!)
>
>> Applications that puke stuff all over the system are pretty
>> much a
>> Windows only travesty, or facilitated by package management
>> tools.
>>
>> Is it really that hard to programmatically set your $PATH
>> and $LD_LIBRARY_PATH?
>
> Designing the OS, you want to figure out how to put in
> place mechanisms that facilitate the application "doing
> the right thing" (by making it hard/impossible for it to
> do the WRONG thing!)
>
> --don
>
>
>
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>