Split-off from bug 45229 http://bugzilla.mozilla.org/show_bug.cgi?id=45229 >------- Additional Comments From dveditz@netscape.com 2000-08-16 08:54 ------- >There are a handful of files that are generated because they depend on which >components you have installed. One is "component.reg", but if you always >distribute a fixed set of components you are perfectly fine pre-generating that >file and shipping it with the binaries (Netscape does that on the Mac due to >start-up time issues). The non-gui utility regxpcom can generate component.reg >The rest of the files are the generated "chrome" files. These, too, contain >only relative paths and could be pre-generated and shipped as well. The build >process creates the file bin/chrome/installed-chrome.txt which is processed on >first startup to generate the actual chrome .rdf files used. I have heard about >a utility called "regchrome" which does this without a gui, but I'm not sure if >it exists of if that was a conversation about how we need it. In any case, if >you are packaging things for distro fire up mozilla once and then include the >files that are generated. We're see a lot of bugs concerning multi-user installations of mozilla and it is overshadowing real bugs such as the "tarballs missing component.reg bug." This is the last major thing preventing just unpacking the tarball and going without running as root first. If it is truely possible for us to ship these chrome files then lets do it and most of these bugs can be gone. Currently you can run mozilla without these chrome files but mail/news and themes do not work at all. So my question for grandrose is "can we add ./mozilla -CreateProfile to the build automation process". If I am correct this generates the necessary *.rdf and overlayinfo files. Below are the files that need to be created. The component.reg and xpti*.dat are already currently being shipped. So, can we just ship the others also? Only in package/chrome: all-locales.rdf Only in package/chrome: all-packages.rdf Only in package/chrome: all-skins.rdf Only in package.orig/chrome: installed-chrome.txt Only in package/chrome: overlayinfo Only in package/chrome: user-locales.rdf Only in package/chrome: user-skins.rdf Only in package: component.reg Only in package/components: xpti.dat Only in package/components: xptitemp.dat References: bug 41057, bug 42184, bug 45229 and bug 51164.

Reassigning to some actually involved with build distributions, Leaf! (Maybe we need a new bugzilla component)

actually, we *don't* ship a component.reg on mac despite the startup time improvements it would give us precisely because just running regxpcom is incredibly flaky and typically crashes the build system. For the same reason, I don't want to run mozilla as part of the build process. If there were a 'regchrome' utility I'd be open to running it as part of the build to see what happens, but frankly I can't rely on mozilla being stable enough on a day to day basis to make it part of the daily build process.

Ok, I guess that makes sense. So, does anyone have this mythical 'regchrome' utility that dveditz thought he heard about? FYI, I just tried ./mozilla -CreateProfile. It created the all-*.rdf files and the overlayinfo directory and it's subdirectories and files. Note that this doesn't start the gui at all, doesn't require user interaction, and could be scripted. It didn't create the other 2 files, user-locales.rdf and user-skins.rdf though.

If our builds produced installed-chrome.txt files with explicit skin and locale select statements (a new feature of this file) I think those files get generated. The syntax to try would be skin,install,select,classic/1.0 locale,install,select,en-US

Heh, I just heard someone mention regchrome on irc and I looked in the source tree and found this: http://lxr.mozilla.org/seamonkey/source/rdf/chrome/tools/chromereg/regchrome.cpp Could something like this be used in the build process?

# and now for the magic (thanks to blizzard for this) MOZILLA_DIR=/usr/lib/mozilla LD_LIBRARY_PATH=$MOZILLA_DIR:$LD_LIBRARY_PATH MOZILLA_FIVE_HOME=$MOZILLA_DIR export MOZILLA_DIR MOZILLA_FIVE_HOME LD_LIBRARY_PATH # register components echo -n "Registering Components... " $MOZILLA_DIR/regxpcom >/dev/null 2>&1 echo "Done" # set up the chrome rdf files echo -n "Registering Chrome... " # set default skin to classic echo skin,install,select,classic/1.0 >> \ $MOZILLA_DIR/chrome/installed-chrome.txt #set default locale to en-US echo locale,install,select,en-US >> $MOZILLA_DIR/chrome/installed-chrome.txt $MOZILLA_DIR/regchrome echo "Done" --- I use that script in the debian postinst, and everything works beautifully assuming regchrome isn't broken of course

What's the status of this now that we have jars?

echoing cls: do we need to do this now that the chrome comes in jar files? No response in 1 week means resolved/invalid, IMHO.

Whether the chrome is in .jars or not is irrelevant, the chrome .RDF files are still used (the contents would reflect the difference).

accepting, i'll see if i can land this change to the build systems for distribution builds on at least windows and unix (and mac doesn't have a super-user concept, so i imagine this isn't a problem for that platform)

Is this really targeted for 1.2? I know a number of groups are working around this by hand or via patches (freebsd port system, for example, has a post-build target to do this). I'm doing this magic by hand (and it's rather annoying). Forcing *nix intallers to run mozilla as root is a minor-to-medium security hole (depending on how paranoid one is), and a significant source for user annoyance.

bug cleanup - all leaf's bugzilla bugs should be assigned to leaf@mozilla.org (not leaf@netscape.com), now and any future bugs created. this should be a one time change, apologies for the spam.

is this still an issue? aren't we running regchrome automatically now?

wontfix