Re: "downgrade", "installed", "upgrade" behavior
Re: "downgrade", "installed", "upgrade" behavior
- Subject: Re: "downgrade", "installed", "upgrade" behavior
- From: Joakim Nyström <email@hidden>
- Date: Mon, 10 Dec 2007 10:53:39 +0100
Thanks for your response!
I understand why you sometimes want to install the same version of an
application once again but should this really be the default
behaviour?. I also still think the GUI it is a bit confusing. It is
one thing to allow a reinstall of the same version but another thing
how to present this to the user. Why is a reinstall displayed as an
"upgrade"? This seems strange to me since according to the
documentation there are the following states: clean, installed,
upgrade, downgrade, and mixed.
Moreover, I haven't got any explanation why the javascript variable
says "downgrade" in the same situation.
The reason I want to make a distinction between "reinstall" and
"upgrade" is to avoid unnecessary restarts. I'm using a distribution
script with several components. One of my components is a third party
package that needs a restart. This is the only component needing
this, which means, if this component is already installed there is no
need for a restart. I really want to minimize the number of
situations where a restart is needed.
It seems like I want the Installer application to work slightly
different from how it is working today. In other words, I guess it is
time for a feature request. This is hard to do, though, without
understanding how it currently is supposed to work.
My remaining questions are as follows:
* How is the javascript variable computed?
* Which "values" could be displayed in the GUI? (I've seen "install"
and "upgrade")
* How is the GUI value computed? (Is it related to the javascript
variable?)
* Can the behaviour be completely controlled with javascript (or by
other method), i.e. can I write code to get exactly the behaviour I
want?
* Are any of the above different for different OS versions? I'm
mainly interested in 10.4 and 10.5.
/ Joakim
8 dec 2007 kl. 01.16 skrev Bill Coderre:
Apple considers it a Good Thing to allow an installer to install
"over" itself. (IE. You install FooApp version 1.0, then you should
be allowed to run the installer again. Then you install FooApp
Updater 1.1, and you can then install the 1.1 updater again. It's
no longer OK to install Foo App 1.0.)
This often fixes "bit rot" issues. ("Bit Rot" is a catchall phrase
that refers to many different ways in which applications get
corrupted. Files sometimes disappear or get corrupted, or get their
owner/group/permissions screwed up, etc. Emphasis on "etc" -- if
you have an app that includes a few tens of thousands of files,
there's a LOT of things to check.)
Yes, this is sometimes a "waste" of user time. But it, in general,
does not cost any disk space, and it might fix a crash.
Note that this means you might have to be more clever about upgrade
preflight/postflight scripts. For instance, if your FooApp 1.0 has
a certain config file, and 1.1 requires a different format of
config file, and for some reason it's totally out of the question
for FooApp to do the config migration during launch, and you
installer is forced to do the migration, you might have to be
careful not to replace the migrated file with another copy, etc etc
etc.
Still, Apple does this for its installers, and I think you can see
why, and therefore I'd suggest you do it too.
The general answer to "how can I decide if this installation is an
upgrade, a re-install, a fresh install, or a downgrade" is, "write
your own code." Sorry, but you probably have a better idea how to
do this than the Installer, anyway.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden