558966 - Make it easier for third-parties to use software update in their builds

Status: RESOLVED FIXED

(Camino Graveyard :: General, enhancement)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

While we essentially support allowing third-parties to use software update (see bug 413709 comment 0 and bug 413709 comment 4), there are two pain points currently:

1) http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/camino/Makefile.in&rev=1.73&mark=78#73 overrides any APP_UPDATES_ENABLED that a third-party might set when configuring or starting their build

2) The DSA public key lives in the plist, which makes replacing it a bit of a pain

The solution to 1, per smorgan's consultation with the internets, is

APP_UPDATES_ENABLED ?= false

I've tested that in a build where I export APP_UPDATES_ENABLED=true and a build where I don't set anything (aka the standard, run-of-the-mill non-tinderbox build), and so far both work as expected.

The solution to 2 is that current Sparkle supports reading the DSA public key from a file in the bundle's Resources (the plist now just provides the DSA key's filename in the SUPublicDSAKeyFile key).

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Documentation for third-parties is here (referencing this bug where it describes those two issues): http://wiki.caminobrowser.org/Development:Providing_Software_Update_for_Third-Party_Camino_Builds

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Patch

This would be the patch to do those two things.

I double-checked the plist-DSAkey -> file-DSAkey change by making that change to a copy of 2.0.1, which then successfully updated itself to 2.0.2.

This patch applies to 2.1-1.9.0 and 2.1-1.9.2; there are some slight context differences in the first two hunks in the project on the 2.0 branch, should we want to take this there (do we?).

Comment 3

[Stuart Morgan]

Comment on attachment 438875 [details] [diff] [review]
Patch

sr=smorgan. Feel free to land or not on 1.9.0 as you see fit; if all goes well it won't matter if it's there, but I can't see any reason not to if keeping them synced makes things easier for you for now.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #3)
> (From update of attachment 438875 [details] [diff] [review])
> sr=smorgan. Feel free to land or not on 1.9.0 as you see fit; if all goes well
> it won't matter if it's there, but I can't see any reason not to if keeping
> them synced makes things easier for you for now.

I was planning on landing it on cvs trunk (1.9.0) regardless, like with all patches that apply both to Hg and CVS trunk, but what I was really asking about was the CAMINO_2_0_BRANCH.

2.0.x is where this would do the most good now to real 3rd-party builders, but it is also the place where the patch is riskiest (in theory; I think the changes are well-defined and understood and reasonably well tested, but it would be wrong not to at least think twice about any changes touching software update).

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed on cvs trunk and http://hg.mozilla.org/camino/rev/98b932e38da1

Comment 6

[Stuart Morgan]

Sorry, I fail at reading. Since you tested update and it worked, I'm fine with pushing it to 2.0.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Landed on the CAMINO_2_0_BRANCH for 2.0.3.