I wrote:
> if you always delete component.reg, *.xpt, *.dll, and *.exe from your mozilla install
> directory you should not have this problem.
JTK wrote:
> always delete component.reg, *.xpt, *.dll, and *.exe
> from your mozilla install directory,
> and these things shall cease to happen amongst us. Isn't that what you're saying?
These two statements are approximately equivalent. However the corollary which you
drew is faulty:
> Shouldn't the installer take care of that?
> > Right now, the installer can't know if you have compatible or incompatible
>libraries lying around.
> Nor should it care. Overwrite them, the ones it itself installed last
> time, and we're done.
You seem to have missed part of the problem.
But what if i had a spellcheck module installed and wanted to use it? (at my own
risk). The installer shouldn't just assume that it can whack my files to upgrade. I
could upgrade just navigator and not mailnews, not aim, not chatzilla. Should the
installer whack all of them just because i'm only installing navigator?
My view is that it shouldn't. If I know what I'm doing then let me do what I want.
If not I should follow the instructions which clearly say install into a fresh
directory.
Perhaps the installer should refuse to install into a used directory? well, we could
do that. But then what's to prevent people from outsmarting the installer my moving
the other files back into the install directory afterwards? If you don't believe
users are smarter than installers then you wouldn't be here.
Sometimes the error is because a file that no longer exists in current builds is being
dynamically loaded because it's still in your mozilla directory. There's no easy way
to tell if a library is outdated or just not updated. And again keeping a complete
list is hard. -- Not to mention the fact that you can't keep a complete list because
you can't control the vendor list. AIM, SpellCheck, JabberZilla, ProtoZilla,
Chatzilla there are many products which will not be updated w/ every build, some of
which will work w/ new builds, some which might break, and many of which are not
controlled by mozilla.org. ideally mozilla might have thousands of such occasionally
compatible components, and keeping that list would be even harder than the basic (and
unmanageable) list for just mozilla.org components.
> > Nor can it know if you have outdated libraries that should be trashed. We could
>teach it a list of such libraries, but eventually installer would be 90%+ of the
>mozilla distribution -- not a good idea.
> No, come on.
I'm sorry, I expect you to read between lines, you seem to be good at that elsewhere,
or at least think you are.
> > Installer's do say something like ~don't install me over an existing install~ and
>perhaps ~may i nuke your existing install~. [note this is binaries, not profile data
>-- although we also don't assert profile compatibility]
> So you're trying to tell me that the installer "can't" overwrite
> binaries and scripts that it installed the day before?
How can it know it installed them? The logs might or might not exist, and some other
installer might have done it. Suppose for example that the problem is actually
jabberzilla. You have JabberFooZilla 0.67 which is compatible w/ mozilla up until
8/20 2am. You get and run the installer from 8/20 4pm it has no way of knowing
anything useful about JabberFooZilla. It can either be aggressive and kill everything
because of course nothing in the directory could possibly be installed by the user
(hint: JabberFooZilla was installed by the user) or it can assume that the user
doesn't want it to randomly trash things (when you ran the installer from 8/19 your
JabberFooZilla wasn't deleted and worked nicely, you were happy).
The basic example is installing just navigator overtop Navigator+Mailnews. In this
case mailnews may or may not function.
Is the correct behavior to trash mailnews? If you upgraded IE from 5.0 to 5.5 or 6.0
would you be upset if MS trashed OE5.0 because you didn't upgrade to 5.5/6.0?
Usually MS doesn't do that. However, when it knows for certain that something is
incompatible, it will force you to run the install process.
Mozilla's installer can't know this [keeping a table of say 5years for 100 to infinity
files for 4 builds plus debugs = too much space (that infinity really messes things
up, but w/o it, you still have a problem)]. MS will usually warn you that things
might break, or that using old things is unsupported (upgrade). Mozilla otoh can live
perfectly happy if you do another install in a different directory (and at least
sometimes an upgrade in the same directory), so having the installer nuke things w/o
warning just because things occasionally break is not a behavior I would advocate.
