Closed Bug 436719 Opened 13 years ago Closed 13 years ago

App specific updater.ini must be alongside updater binary in xre

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.1a2

People

(Reporter: mossop, Assigned: mossop)

References

Details

Attachments

(4 files)

updater.ini contains localised strings and post-update stuff that is generally specific to the application (Firefox's contains the Firefox name f.e.). However it is currently required that this file sits in the same directory as the updater binary.

For an xulrunner application the updater binary is part of xulrunner. So unless you are packaging your own xulrunner you cannot have an appropriate updater.ini.

We should use an updater.ini from the app dir if one is available.
Attached patch patch rev 1Splinter Review
This makes the update code always use an updater.ini file in the application directory and an updater binary from the gre. In the case of non-xulrunner apps like Firefox on non-OSX that works out the same as now. For OSX we have to put the updater.ini outside of the updater app, and the updater app must pull from the new location.
Assignee: nobody → dtownsend
Status: NEW → ASSIGNED
Attachment #329506 - Flags: review?(benjamin)
Which VCS/branches are you aiming this at ? Any transition req'd for Fx 3.0.x ? Might also have to tweak our update verify scripts.
(In reply to comment #2)
> Which VCS/branches are you aiming this at ? Any transition req'd for Fx 3.0.x ?

Was just aiming for 1.9.1. I don't think there is any real urgency to get it onto 1.9.0.x though it'd be handy.

The only changes necessary for Firefox are included in the patch I believe. The only actual change there is that updater.ini is moved to a different place on OSX builds.

> Might also have to tweak our update verify scripts.

What do these scripts do and how to they work?
(In reply to comment #3)
> > Might also have to tweak our update verify scripts.
> 
> What do these scripts do and how to they work?

Looks like those scripts don't copy the updater.ini with the updater binary at the moment (which is fine, the update process just doesn't display a UI if it has no strings), so no changes should be necessary.
Comment on attachment 329506 [details] [diff] [review]
patch rev 1

Rob, could you take a look at this also? I fear mysterious side-effects in this code.
Attachment #329506 - Flags: review?(robert.bugzilla)
Attachment #329506 - Flags: review?(benjamin)
Attachment #329506 - Flags: review+
Product: Firefox → Toolkit
Comment on attachment 329506 [details] [diff] [review]
patch rev 1

Yep, this makes sense. r-me
Attachment #329506 - Flags: review?(robert.bugzilla) → review+
This fixes up the updater.ini for OSX for Thunderbird and Seamonkey.
Attachment #332686 - Flags: review?(philringnalda)
Attachment #332686 - Flags: review?(benjamin)
Comment on attachment 332686 [details] [diff] [review]
comm-central patch

Thx.
Attachment #332686 - Flags: review?(philringnalda) → review+
Attachment #332686 - Flags: review?(benjamin) → review+
Additional patch that removes the old updater.ini on update in OSX only
Attachment #333198 - Flags: review?(benjamin)
Attachment #333199 - Flags: review?(philringnalda)
Attachment #333199 - Flags: review?(benjamin)
Attachment #333198 - Flags: review?(benjamin) → review+
Attachment #333199 - Flags: review?(benjamin) → review+
Comment on attachment 333199 [details] [diff] [review]
Same for comm-central

If anyone ever figures out a simple set of rules for order in removed-files/packages-static, so it's possible to say "yes, that's the right place to put that line," there'll be a pony for them.
Attachment #333199 - Flags: review?(philringnalda) → review+
Landed:

http://hg.mozilla.org/index.cgi/mozilla-central/rev/e9932544d4f5
http://hg.mozilla.org/index.cgi/comm-central/rev/afd9373bce4d
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
You need to log in before you can comment on or make changes to this bug.