234479 - [LINUX]Employ surgical upgrade strategy (only delete files created by the installer and emptied directories)

Status: RESOLVED WORKSFORME

(SeaMonkey :: Installer, enhancement)

Description

[timeless]

Spun off from bug 69153. The original unstated goal was to build an uninstaller
that considered the installer logs as input when uninstalling.

Bug 69153 Comment #49 From Syd Logan 2002-06-03 23:23 PST

... The key to the fix is we need to ensure is that we only remove
files that we had installed previously....

Well, we have to consider [the case of a /usr/mozilla-bin binary]. How can it be
done? One way would be to force the installer to only allow clobbers of
directories that we have created.
If the user had installed into an existing directory, then we either disallow
upgrades there, or we warn them strongly that what they are about to do will
tube any and all files. How can we know that the install directory was created
by us in a previous install? We could simply create a marker file in the code
that creates a directory in response to the user selecting a directory that does
not exist (The directory you are installing to does not exist, would you like to
create it?. Even better, the marker file would contain an ls(1) of the contents
of the directory after the install (plus any files we know are created by the
browser for this version, the marker file could be constructed by the build team
and included in the browser.jst file). When we come back and install, if the
directory exists, and it does not have the marker file, then we better warn the
user since it might have been something like /usr. If the marker file is there,
and the contents don't match an ls of the directory, we should warn the user as
well (because the directory may contain something that was not installed by us
that they do not want deleted, a message like "The directory appears to contain
files that were not a part of the previous install of [Mozilla/Netscape]. We
suggest you make a backup of the directory before installing here, or choose
another directory".

Bug 69153 Comment #50 From Syd Logan 2002-06-04 00:08 PST

additional comments from an IRC log:

<nick> we allow empty dirs
<syd> good point
<nick> in fact, I did something like that
<nick> and later removed the code
<syd> we could check for empty dirs and treat that similar to our creating it,
and write the marker file


Bug 69153 Comment #51 From Nicolás Lichtmaier 2002-06-04 10:11 PST

Well... this is what I [propose]:

Mozilla can be installed in 3 types of directory:
1) non-existant
2) empty
3) mozilla only directory, marked with a marker file.

If the directory hasn't got the marker file, it exists, and it has already other
files [there] will [be] no way to install Mozilla there.
When installing Mozilla will create the marker file at the start of the process,
so that to allow reinstalling if the installer crashes. Leaving the marker file
the installer is saying "I know I've created this directory, or I found it
empty, so you can delete this in the future because it's just Mozilla".

One unresolved problem: How do we implement this for the first time? Should we
rush to add at least the marker file creation to 1.0?

---
Useless note: we missed 1.0 :).

Comment 1

[Robert Parenton]

Confirming

Comment 2

[Alexander Opitz]

More discussion needed on what is the best way to update/uninstall 'older' mozillas.

Comment 3

[Andrew Schultz]

I filed bug 234741 to prevent users from getting into the situation that most
users are getting into here (installing to /usr/bin, etc).

Note that the "surgical upgrade" path (only removing files installed by previous
installer) is one filled with pain.  The Windoze installer used to do this and
it resulted in the fun of bug 195600.  It was ripped out and replaced with
something somewhat closer what Linux already has in bug 210731.

IMO, the installer should clobber everything in the directory (after telling the
user) except for the plugins directory.

Comment 4

[Alexander Opitz]

I hope we can make a discussion here, but it seems to be stopped. Also I don't 
know how the FF/Thunderbird installers works now, are they new, are they the 
same with an other config file?
If they are new, how they will work on the mentioned problems? Hope someone can 
help me on this.
And as I've seen some screenshoots of a better Update UI for Firefox ... are 
there changes in XPInstall that also mozilla the suite can use? Or does all 
forgett this and work towards mozilla2.0? But how we want to resolve this there?

Comment 5

[Alexander Opitz]

The screenshots I meant are from Ben on http://weblogs.mozillazine.org/ben/ ...
maybe I should speak with him, if I get a pong on irc. If someone on this bug
knows more, anything is welcome, here or on #mozilla/#developers

Comment 6

[Logan Ingalls]

*** Bug 259789 has been marked as a duplicate of this bug. ***

Comment 7

[Jo Hermans]

*** Bug 294469 has been marked as a duplicate of this bug. ***

Comment 8

[Jo Hermans]

*** Bug 264771 has been marked as a duplicate of this bug. ***

Comment 9

[Kevin Brosnan]

*** Bug 294873 has been marked as a duplicate of this bug. ***

Comment 10

[Jo Hermans]

*** Bug 258548 has been marked as a duplicate of this bug. ***

Comment 11

[Joseph "What is reality?" Brenner]

I'm glad to see that this issue is at least still being discussed, but I'm 
astounded that anyone still needs to be convinced that it's a problem. 
Possibly I should write an essay: "'rm *' considered harmful".

Comment 12

[Matthias Versen [:Matti]]

The linux installer is discontinued