10757 - Wizard-run installs get wrong directories

Status: VERIFIED FIXED

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

Description

[Daniel Veditz [:dveditz]]

When the wizard launches installs through xpistub.dll the installs all think
the program directory is where the wizard is, not where xpcom is.
 - files installed in the wrong place
 - component.reg in the wrong place
 - install.log in the wrong place
 - SmartUpdate page won't be able to find the registered stuff (registered
under wrong Communicator directory)

Not sure we have many options. There may be some way to hack nsFileSpec so we
can fake it out about where the program directory is. Other than that, the
wizard will have to lauch a new process to do the install (i.e. xpistub.EXE).

A separate process means the wizard will have trouble showing the progress. We
could have the wizard simply launch apprunner to do it, or get into the muck of
inter-process communication.

Comment 1

[Daniel Veditz [:dveditz]]

Samir should be on this one too.

Do the Mac and Win wizards work the same way? The wizard itself goes in a temp
dir. The first version Sean showed me had the core unpacked and run in the
final dir, with all of the problems already listed (the wizard was considered
the app). Later I Sean mentioned he was going to unpack the core also in the
temp dir, but then XPInstall it into the final dir.

One advantage of that is that the basic script wouldn't have to overwrite the
new files. That would be a nice thing on Win9x, and would also leave more
reassuring messages in the install.log.  It also helps with this problem if we
can agree to do it this way for both wizards. For one thing I think we'd only
have to hack xpinstall to handle this rather than the core directory service.

In this scenario xpistub would call AutoReg with NULL to initialize XPCOM in
the temp directory -- creating a temp components.reg. xpistub would still have
to be passed the target directory, which it will use to override the "Program"
directory, the version registry directory, and the location of the install log
(if we want the initial install to create one).

At the end of the script we'd have to somehow register the new files. But
that's OK because our scripts will have to be able to do that anyway in order
for XPInstall upgrades to work.

Any future thoughts about this plan? Is the double-install of the core files an
OK plan?

Comment 2

[Daniel Veditz [:dveditz]]

The solution I tried was to fool XPInstall about the Program directory, but
leave the deeper concept of Process dir alone. The install.log and the
components.reg still are created in the wizard directory. It appears to work OK
if the components.reg cannot be created (as would be the case with a CD
install, for instance)

This may not be the end of it...

Comment 3

[Jimmy Lee]

This will be and only can be verified when the install wizard uses xpinstall to
install xpis.

Comment 4

[Jimmy Lee]

Build 9/24/99

This installer appears to install fine.  Marking Verified.

Comment 5

[leger]

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/da4430623390
[fenix] For https://github.com/mozilla-mobile/fenix/issues/10757: remove no-op Experiments code and dependency.