Closed Bug 116722 Opened 23 years ago Closed 23 years ago

Mozilla should have an update agent

Categories

(Core Graveyard :: Installer: XPInstall Engine, enhancement)

x86
Windows ME
enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: joakim_46, Assigned: slogan)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

Everytime we want to update Mozilla to the latest build we have to
download an entire package and not the modified files only. Mozilla
should have a update agent to update any Mozilla build to the latest one.

Reproducible: Always
Steps to Reproduce:
1. Start Mozilla
2. There's no update feature

 

Actual Results:  Mozilla needs an update agent.
Over to xpinstall engine for consideration.
Assignee: asa → syd
Status: UNCONFIRMED → NEW
Component: Browser-General → Installer: XPInstall Engine
Ever confirmed: true
QA Contact: doronr → jimmylee
the 'any' bit makes this beyond impractical, it makes it impossible.  there is 
no way for us to know about all possible files and whether they are compatible 
w/ new files or need to be removed.

beyond that, mozilla builds generally include changes for all distributed files 
so this isn't very useful.

a chrome diff system might be interesting, but i'd imagine the overhead to be 
well beyond any savings anyone might imagine gaining.
From build to build, milestone to milestone every library gets changed.
DOwnloading the changed files is downloading everything. Failing to download
everything that changed means your build likely won't run.

Mozilla.org could set up an "update" page if it thought the work was worthwhile.
For users who don't install all components it could detect which components are
installed and default to updating only those components. That's not going to
save much for the typical mozilla nightly downloader, but it does maybe simplify
things a little. Enough to be worth the effort? Dunno.

XPInstall has a broken patch mechanism. Once cleaned up this could offer some
download savings (possibly significant) but it has several significant drawbacks
(which is why we haven't spent much effort fixing it). One, patches are fragile.
If the user doesn't have exactly the version we expect for each file then patch
will fail. For a community that likes to futz with things, or even build their
own, this is not a recipe for success. Two, patches are very version specific
conversions from A to B. We could perhaps create day to day patches, but people
download miscellaneous nightlies and we could never cover all the combinations.
We could maybe handle milestone to milestone.

There's a separate enhancement bug somewhere that Mozilla should notify users
when an update is available. That'd hook into the "update" page I mentioned above.

None of these things are exactly what this bug is asking for. The way we build
things and given the fragile interfaces between components people will always
have to download all the files which have changed, and the way we develop things
(fragile interfaces) most files change fairly often.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Marking Verified.
Status: RESOLVED → VERIFIED
*** Bug 185248 has been marked as a duplicate of this bug. ***
Wouldn't it possible to check what all the differences are between all the old
and new versions of the files and makes patches for all files (that changed)
based on that?
Maybe every file needs to be patched each time, but at least the download will
smaller.
> Maybe every file needs to be patched each time

Based on my survey of the last couple of milestones, yes it does.

Give that, the download would not be any smaller (these are _binary_ files, not
text files; patching them is basically impossible since it changes the layout
and this necessitates cascading changes elsewhere in the binary).
*** Bug 261511 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.