I noticed while doing some testing for bug 414560, that the update manifest for a partial update is different when generated by make_incremental_updates.py, only on the mac though. Here's a diff between what patcher2 generates (slow mode), and what make_incremental_updates.py (fast) gives: < patch-if "Contents/MacOS/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}" "Contents/MacOS/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/install.rdf.patch" "Contents /MacOS/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/install.rdf" > patch "Contents/MacOS/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/install.rdf.patch" "Contents/MacOS/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/install.rdf" 51d51 ie slow mode is uses patch-if and fast isn't. (historical note: we use patch-if for stuff in extensions/ because DOMi and Talkback used to be optional installs on Windows, so the updater had to have some concept of "patch this if it's present, otherwise carry on"). This is a mac only "problem" because the fast mode using if filename.startswith("extensions/"): while on Mac it begins Contents/MacOS/extensions/...

Same for searchplugins, the code is at http://mxr.mozilla.org/seamonkey/source/tools/update-packaging/make_incremental_updates.py#57

It looks like the add-if was susceptible to this too, so I fixed it up as well.

Comment on attachment 416978 [details] [diff] [review] Use patch-if on Mac extensions/ and searchplugins/ http://hg.mozilla.org/mozilla-central/rev/b45c4ef383b2

Checking in make_incremental_updates.py; /cvsroot/mozilla/tools/update-packaging/make_incremental_updates.py,v <-- make_incremental_updates.py new revision: 1.12; previous revision: 1.11 done Holding off on landing to 1.9.0 and 1.9.1 pending kick-off of 3.0.17 and 3.5.7.

That's OK, this won't get picked up in releases until we do a new UPDATE_PACKAING_Rn tag in CVS.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5c9730741212 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/3887e9ab7690