Firefox for Corporations
Sergey Yanovich
vanishes regularly. At the moment, this issue is somewhere below
horizon. The purpose of this post is to revive the discussion.
The current status of this issue can be drawn from these two resources,
both looking up-to-date:
http://wiki.mozilla.org/Firefox3/Product_Requirements_Document#OS_platform_integration
https://bugzilla.mozilla.org/show_bug.cgi?id=231062
It can be inferred, that there is a general agreement, that large-scale
corporate deployment is one of the biggest growth areas for Firefox. At
the same time, results of cost/benefit analysis don't justify resource
allocation.
The biggest obstacle to corporate deployment seems to be the absence of
a Windows Installer (.msi) package for Firefox, and resulting lack of
support for Active Directory and Group Policy Management technologies.
To provide a clue for linux administrators/users, the difference between
the current w32 Firefox installer and the MSI is approximately the same
as between 'make install' and 'yum/apt install'. Both serve well enough
in a typical scenario, but the latter is far superior in dealing with
edge cases. That difference is rooted in the underlying approaches: the
former methods operate in terms of process, while the latter think in
terms of system state.
After doing a brief study of available tools, I would like to propose a
three-stage nsis->msi migration strategy:
1. Stage One
There seems to be a quite easy way to produce MSI package with Mozilla
Build System on the fly. This will require:
* adding WiX to Mozilla-Build package;
* adding msi Makefile target;
* writing a static WiX fragment for the main executable, registry keys
and shortcuts;
* writing a perl or python script to transform WiX's tallow.exe output
into WiX fragment. The bulk of work in the script will be GUID generation.
However, Windows Installer burdens its users with long list of
requirements. This list includes limits on using same file names in the
same location in different versions of application under certain
circumstances. On-the-fly GUID generation is one of such circumstances.
As a result, there are going to be consequences:
* different release will require different installation directories.
Like '/c/Program Files/Mozilla Firefox 3.0.0.x' for 1.9 branch;
* Windows Installer patches (MSP) won't be available. Because of
different installation directories, every file will need to be patched
in full size.
During this stage, both formats need to be supported.
2. Stage Two
The real solution is to create a separate WiX source fragment for each
installed file. Manual management of them in the scale of Mozilla looks
impossible. However, this burden can be put on the build system:
* defining a set of Makefile variables in rules.mk for MSI categories,
and a set of makefile rules for creating WiX fragments using those
variables;
* formulating library versioning policy (bug 302046);
* setting those variables in the corresponding Makefile.in's;
* replacing tallow.exe run in msi Makefile target.
As a result, the build system will produce a well behaving MSI. It will
also be possible to manually create installer patches.
3. Stage Three
The final step is to automate patch creation for stable branches, and
switch automatic update system to use MSP files. This includes:
* Makefile rules for patches in msi Makefile target;
* Respectful changes to Automatic Updates module.
TIME ESTIMATE
Stages 1 and 3 are human scale pieces of work. The impression is that
each can be done within a 40 hours. The third * in Stage 2 is project
scale. It should probably be done by writing a script. The script will
locate each installed file in the source tree and patch the
corresponding Makefile with generated variables. I don't have experience
with automatic rewrites, but from what I've seen, it can probably be
done in 120-160 hours. This estimate gives a chance to complete the
migration before or near Firefox 3 release.
I am going to create a proof of concept patch to the build system to
generate a MSM and MSI for xulrunner. All kind of feedback is
appreciated.
This has also been posted to m.d.platform, m.d.planning, and m.d.builds
. Since the issue requires project-wide changes, I think, that
m.d.platform is the right place for follow-ups.
Thanks to Gen Kanai for a link to this list.
Kind regards,
--
Sergey Yanovich