284589 - ability to install multiple update mars during one update

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Chase Phillips]

Where it makes sense, users should be able to download multiple updates at once
and then have them install in the order specified by the update server.

Comment 1

[stupendo44]

Are you referring to installing a firefox update and extension updates at the
same time? Multiple extension updates can already be installed at the same time,
but firefox updates can't at the same time.

Comment 2

[Caleb]

I think that what Chase means is this:

If you are running Firefox 1.1 and the latest version out there is 1.1.4, the
update service should download the following updates

* FF 1.1 -> 1.1.1
* ...
* FF 1.1.3 -> FF 1.1.4

And install them at once, instead of making you download each of those and
restarting afterwards.

Comment 3

[Darin Fisher]

The solution for Firefox 1.5 is to have users download a full update when
skipping over releases.  Maybe at some point in the future we might want to
support multiple patches, so giving this a future target ;-)

Comment 4

[Scott Gifford]

Using recent branch nightlies, after being offline for a few days, I had to run
"Help | Check for Updates" several times to get to the latest version.

Not sure if the fix Darin mentions hasn't been done yet, if this is an artifact
of testing mode, or if something is misbehaving on my system.  But this FAQ:

    http://wiki.mozilla.org/Mozilla_QA_Community:Software_Update:FAQ

didn't mention anything about it, so I thought I'd add a note.

Comment 5

[alanjstr]

See 306999 for nightlies patching

Comment 6

[Chase Phillips]

There is no difference in the client between a release MAR patch or a nightly
MAR patch.  These types of updates are handled differently by the server and
sent to the client for download and installation.

This bug is meant to target the client's ability to update, not the server's
ability to send updates grouped together.  Bug 306864 and bug 306099 address the
infrastructure/general update system issues.

Comment 7

[Jo Hermans]

see bug 306864

Comment 8

[Chase Phillips]

Nominating this bug as blocking for one of 1.8.0.1, 1.8.1, and 1.9a1.  Depending on what it would take, we should consider it for the earliest release of the three that it could happen in.

Rationale: we're now spending a majority of time redundantly creating partial patches between releases.  An example is that when we create a diff between Firefox 1.5b2 and 1.5 for en-US on Windows, most of this patch can be reused for the same update between fr, ga-IE, and every other locale on Windows.  If we could install multiple updates at once, we could have the client install one patch per platform per update that contains most of the changes, then another patch for the locale-specific portions of the installation per platform per locale per update.

For 1.5b2, 1.5rc1, and 1.5rc2 to 1.5, we currently have 285 partial patches using 123 MB.  Contrast that with having 9 patches (3 updates, 3 platforms) containing the bulk of the ~700 KB of release differences and 285 patches containing the small localization changes between those releases (9.15 MB).  Add branding specialization and there's another dimension that at least doubles the set of patches we need to create.

The numbers only continue to grow.  By unchaining the largest parts of the patch that aren't dependant on specializations of the releases' attributes (eg locale or branding), we can realize a cost savings in time to create the patches and disk space used for each release.

Comment 9

[Daniel Veditz [:dveditz]]

Too big, scary, and not even started to consider for .0.1

Comment 10

[Darin Fisher]

I think this bug is WONTFIX.

IMO we should keep the client butt simple, and shift as much complexity as possible to AUS where it can be more easily modified.  I think this bug should
be fixed by having AUS update the client to the latest build.

Comment 11

[Darin Fisher]

After talking to Chase about this, I realize that what is really needed is just the ability to break a single update into component parts (multiple MAR files perhaps).  What I objected to was using such a mechanism to update the browser from version 1.5 to 1.5.1 to 1.5.2 all in one shot.  That wouldn't work properly without restarting the browser in between patch applications, which would be very ugly for users.  (Why?  Because things like nsPostUpdateWin.js need to run after an update, and updater may change after an update.)

However, if we are only talking about factoring a single MAR into component parts then we can easily support downloading the separate files and staging them all to be applied by one invocation of the updater.

Comment 12

[alanjstr]

(In reply to comment #11)
>  What I objected to was using such a mechanism to update the browser
> from version 1.5 to 1.5.1 to 1.5.2 all in one shot.  

That's exactly what I was hoping for.  Whether it be for nightly builds, or because a computer just hasn't been updated in a while.  

> That wouldn't work
> properly without restarting the browser in between patch applications, which
> would be very ugly for users. 

Well, then wouldn't that be in scope for this bug, to not have to restart?

Comment 15

[Steffen Wilberg]

This bug is about a series of minor updates.
You don't have to update from e.g. 3.6.10 to .11, .12, .13, .14, and .15. Instead, we directly update to .15 using the complete mar.

Skipping from e.g. 3.6.10 directly to the new major version 4.0 without going to the latest minor version 3.6.x first is a different bug.

--> WFM.

Comment 16

[Robert Strong (they/them - no direct email)]

What he was requesting is to download multiple updates and applying them sequentially.

Reopening for now though this will likely be wontfix'd

Comment 17

[José Jeria]

(In reply to comment #16)

See comment 9 and comment 10

Comment 18

[Robert Strong (they/them - no direct email)]

(In reply to comment #17)
> (In reply to comment #16)
> 
> See comment 9 and comment 10
I'm quite aware of comment #9 and comment #10 and for the most part agree.

Please see http://www.mozilla.org/projects/toolkit/review.html under Application Update

Comment 19

[alanjstr]

So what are the use cases for this?
1) Incremental patches to go from .0 to .1 to .2
2) Apply common changes in one MAR and locale-specific changes in a separate MAR.

I think that Mozilla has decided that for the first one it is easier and more cost effective to just deliver a full upgrade than multiple incremental updates.

Is releng still interested in the second use case?

Comment 20

[Robert Strong (they/them - no direct email)]

The incremental case isn't all that valuable because the partial mars can fairly quickly reach the size of the complete mar.
 
A couple of the use cases:
ability to create a non-locale mar and a locale mar.
oem distributions with a base Firefox mar and a customization mar.

The locale case is no longer possible since the locale is now in omni.jar

The value of doing this isn't all that great and the additional complexity is rather high so I'm wontfixing this.