Closed Bug 10533 Opened 25 years ago Closed 25 years ago

[feature] Need a new version registry for mozilla

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P1)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: dougt, Assigned: dveditz)

References

Details

(Whiteboard: [PDT+] 2/15) 

If Communication is open, you can not successfully install software.
Communicator keeps the version registry open and locked for writting.  If you
try to install software via xpinstall, the version registry will be
un-modifiable and you will not be able to query for that software in the future.
 This is bad.

We need to either suggest that communicator be closed while installing software,
or mantain a seperate database.
This is bad.  Isn't there a third option of changing the way that Communicator
handles the version registry back to the way it used to be in 4.x?
This problem is due to 4.x, not mozilla, and therefore the problem. (It may
only be a problem with 4.5 -- the roaming/profile stuff was lazy and never shut
the registry -- but 4.0x could easily have the same problem due to SmartUpdate.

If Communicator 4.x is running the registry is open. We can
 - detect the registry isn't writable and bail before install
   (bail before download even better if possible!)
 - use a different registry

The latter obviously messes up the SmartUpdate service unless we jump through
lots of hoops (like reading from both registry and writing only to the new one.
Not all that hard, sort of what we do on Unix already -- but a PITA).
The reason this wasn't a problem in 4.x is because we didn't let people run two
copies at the same time.
OK.  I think I misunderstood.  If the problem arises only when both Communicator
and mozilla are open, it is not such a bad thing.  The only real issue that I
see is for the initial install.  Will that be a problem?
Is running communicator and running mozilla at the same time common?  I
routinely run both IE and Communicator.
Summary: If Communication is open, you can not successfully install software → If Communicator 4.x is open XPInstall doesn't update registry
Severity: critical → blocker
Priority: P3 → P1
Target Milestone: M9
Severity: blocker → critical
Blocks: 11020
Summary: If Communicator 4.x is open XPInstall doesn't update registry → [feature] If Communicator 4.x is open XPInstall doesn't update registry
Target Milestone: M9 → M10
setting target milestone to M10.
a decision from today's team meeting
Blocks: 12805
Target Milestone: M10 → M14
Summary: [feature] If Communicator 4.x is open XPInstall doesn't update registry → [feature] Need a new version registry for mozilla
Several problems:
 - Communicator could keep the old one open
 - Uninstall format is different
 - Delete/replace list is incompatible

A new registry would solve these problems, whether mozregistry.dat or a new
mozversions.dat
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
Hey folks, I'd be willing to help test this as well when you get close to a
solution. And yes Doug, I routinely run both Communicator and Mozilla at the
same time. Sometimes even IE too. But then I'm a freak.
Keywords: beta1
PDT needs an update on this to determine PDT+ or - status for beta1...thanks!
pdt - please provide requested data
dveditz, can you explain beta1 impact here?  Thanks! Adding [NEED INFO] to 
Status Summary.
Whiteboard: [NEED INFO
Whiteboard: [NEED INFO → [NEED INFO]
"Need Eng to Verify"

By default we are storing version info into the Netscape (4.x) version 
registry, but the mozilla data has a different format that 4.x will choke on. 
We need a mozilla (5.x) version registry.
Whiteboard: [NEED INFO]
PDT is confused by the description of impact.  We all run 4.x *AND* Seamonkey 
together, and yet this bug seems to say we can't without repairing this bug.  
What are we missing?
Whiteboard: [NEED INFO]
Mozilla is quietly corrupting your 4.x version registry with bad data, which 
eventually will cause badness when you try to use the SmartUpdate site from 4.x
(Should I dig out what percentage of site registrations are due to the 
SmartUpdate pages?)

This is nothing more than using a new file name. Ok, a little more, but not 
much.
Whiteboard: [NEED INFO]
I'll do it for you Dan. :) When I left last July, SU registered somewhere on 
average of 15% or more of Netcenter users. From the limited (and granted, 
incomplete) data I had gathered I surmised approximately 20% of that group had 
had some sort of problem with SU. One look at the archives of netscape 
newsgroups, or simply by polling the champions (many of whom say "DON'T use 
SU!") would push the point that it *really* needs to be bulletproof this go 
round. Add this in with past 'silent respins' and the inadvertent wide release 
of 4.71 and things can spiral out of control pretty quickly. -jim race
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 2/15
How 'bout "Mozilla Versions" on mac, "mozver.dat" on Windows, and either 
"mozver.dat" or "mozversions" on Unix.
Fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Build: 2000-02-15-10-M14(WIN), 2000-02-15-09-M14(MAC), 2000-02-15-10-M14(LINUX)

mozver.dat for Windows, Mozilla Versions for Macintosh, /.mozilla/mozver.dat for 
Linux.  We write to the new registry.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.