Closed Bug 51677 Opened 24 years ago Closed 20 years ago

Ship pre-generated chrome files if possible

Categories

(SeaMonkey :: Build Config, enhancement, P4)

x86
Linux
enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mozilla, Assigned: chase)

Details

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.
Blocks: 42184
Keywords: nsbeta3
Whiteboard: [need info if this is possible]
Reassigning to some actually involved with build distributions, Leaf! (Maybe we
need a new bugzilla component)
Assignee: cls → leaf
No longer blocks: 42184
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)
Status: NEW → ASSIGNED
Severity: normal → enhancement
Keywords: nsbeta3
Whiteboard: [need info if this is possible]
Target Milestone: --- → mozilla1.2
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.
Assignee: leaf → leaf
Status: ASSIGNED → NEW
Target Milestone: mozilla1.2alpha → mozilla1.7beta
is this still an issue?  aren't we running regchrome automatically now?
Assignee: leaf → cmp
Priority: P3 → P4
QA Contact: granrosebugs → leaf
Target Milestone: mozilla1.7beta → ---
wontfix
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.