576760 - no longer need to force component manifests in updates

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Mark Banner (:standard8)]

components.list used to be forced to be refreshed on each update to ensure other extensions/applications didn't fiddle with it.

Now it has been renamed to components.manifest, the refreshing has been lost. Hence it should be a blocker, as this is a regression from previous functionality.

Also, what about interfaces.manifest? It appears to be generated but not packaged.

This looks like the affected line:

http://mxr.mozilla.org/comm-central/source/mozilla/tools/update-packaging/make_incremental_update.sh#51

However the patcher config files (for build automation) also need an update:

http://mxr.mozilla.org/mozilla/source/tools/patcher-configs/

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

I don't see a components/components.manifest in recent trunk builds, just a components/browser.manifest. Is that from bug 568691 comment #49 ? Also, the manifest in the mac universal build only has comments in it.

Release wise the file will be new in 4.0b2.

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #1)
> I don't see a components/components.manifest in recent trunk builds, just a
> components/browser.manifest. Is that from bug 568691 comment #49 ?

Yes, you're right, it should be browser.manifest from a bit of investigation:

http://hg.mozilla.org/mozilla-central/rev/b7631123fd4d
http://hg.mozilla.org/mozilla-central/rev/ea142ed538fc

and in fact, that name will vary per-app, which is probably going to make changing http://mxr.mozilla.org/comm-central/source/mozilla/tools/update-packaging/make_incremental_update.sh#51 interesting (but the patcher-configs are per-app so they will be fine).

> Also, the
> manifest in the mac universal build only has comments in it.

Mine has both (though you have to go a fairly long way down through the file).

> Release wise the file will be new in 4.0b2.

True, but nightly updates need it, and we'll need it for 4.0b3 (or final, whichever it is).

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Thanks for digging. Looks like requested_forced_updates (at line 51) can list files that aren't in the package without any problems.

I'm traveling to the summit so if this needs an urgent fix then r+ to switch to browser.manifest and add Thunderbird, SeaMonkey, etc as required, at http://mxr.mozilla.org/comm-central/source/mozilla/tools/update-packaging/make_incremental_update.sh#51
Assuming there are no name collisions of course, but it seems unlikely.

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Fix up nightlies

This should fix up Firefox, Thunderbird, and SeaMonkey builds based on mozilla-central but I still need to test that.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Fix Firefox4.0 releases

Don't technically need this before b3 (since the partial will ADD the new file just like the complete) but not going to harm anything.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 457763 [details] [diff] [review]
Fix Firefox4.0 releases

Checking in moz193-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz193-branch-patcher2.cfg,v  <--  moz193-branch-patcher2.cfg
new revision: 1.6; previous revision: 1.5
done

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 457761 [details] [diff] [review]
Fix up nightlies

After creating a partial manually with this patch and unpacking it again, I get this diff against the mars we create with stock m-c:

$ diff -ru unpacked-{old,new}
Only in unpacked-new/Contents/MacOS/components: browser.manifest
diff -ru unpacked-old/update.manifest unpacked-new/update.manifest
--- unpacked-old/update.manifest	2010-07-19 13:39:08.000000000 +1200
+++ unpacked-new/update.manifest	2010-07-19 13:39:24.000000000 +1200
@@ -4,6 +4,7 @@
 patch "Contents/MacOS/chrome/en-US.jar.patch" "Contents/MacOS/chrome/en-US.jar"
 patch "Contents/MacOS/chrome/pippki.jar.patch" "Contents/MacOS/chrome/pippki.jar"
 patch "Contents/MacOS/chrome/toolkit.jar.patch" "Contents/MacOS/chrome/toolkit.jar"
+add "Contents/MacOS/components/browser.manifest"
 patch "Contents/MacOS/components/browser.xpt.patch" "Contents/MacOS/components/browser.xpt"
 patch "Contents/MacOS/components/libalerts_s.dylib.patch" "Contents/MacOS/components/libalerts_s.dylib"
 patch "Contents/MacOS/components/libbrowsercomps.dylib.patch" "Contents/MacOS/components/libbrowsercomps.dylib"
Which looks like it should to me.

Firefox has just browser.manifest; SeaMonkey has browser.manifest and mail.manifest; Thunderbird has mail.manifest and newsblog.manifest.

Comment 8

[Mark Banner (:standard8)]

Comment on attachment 457761 [details] [diff] [review]
Fix up nightlies

This looks fine, but from what I can tell bug 579178 is now going to change the name of these new manifests... requesting feedback from Benjamin as he's working on that bug.

Comment 9

[Benjamin Smedberg]

I don't think we should fix this. It's a rather extreme form of paranoia: you can modify any of the .manifest files in the shipping directory, and I don't think we want to force all of them.

Comment 10

[Mark Banner (:standard8)]

(In reply to comment #9)
> I don't think we should fix this. It's a rather extreme form of paranoia: you
> can modify any of the .manifest files in the shipping directory, and I don't
> think we want to force all of them.

So what was the point of forcing components.list to be refreshed each time in 3.6?

Comment 11

[Benjamin Smedberg]

We were afraid that "bad" stuff would modify it. That hasn't happened, as far as we know, and I don't think the paranoia is worth it.

With omnijar this will mostly go away anyway, I think.

Comment 12

[Nick Thomas [:nthomas] (UTC+12)]

We have been refreshing components.list in 3.6.x and 4.0 releases (and nightlies), so there has been a disincentive to modify the file if you are a bad guy. I'll prepare a patches to remove that. We can start doing that again if it becomes a problem.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

Morphing - was 'browser.manifest is not forced to be refreshed on each update'.

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Stop forcing lists in 3.6 & 4.0 releases

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Stop forcing lists in nightlies

We'd land this on m-c, m-1.9.2. And possibly 1.9.1 too, it's there but a no-op.

Comment 16

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 464212 [details] [diff] [review]
Stop forcing lists in nightlies

http://hg.mozilla.org/mozilla-central/rev/a6e8516e1d78

Comment 17

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 464179 [details] [diff] [review]
Stop forcing lists in 3.6 & 4.0 releases

Checking in moz192-branch-patcher2.cfg;
new revision: 1.33; previous revision: 1.32

Checking in moz20-branch-patcher2.cfg;
new revision: 1.5; previous revision: 1.4

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

Standard8, I happened across this bug today and noticed that Thunderbird is forcing components.list in a few patcher config files still. Expected ?

Comment 19

[Mark Banner (:standard8)]

(In reply to comment #18)
> Standard8, I happened across this bug today and noticed that Thunderbird is
> forcing components.list in a few patcher config files still. Expected ?

Nope, forgotten. I've filed bug 641974 to drop them in our trunk configs. I'm going to leave 1.9.2 as they are as I know we're probably still in a little bit of danger of a few silly people trying to modify those files.