Is it really necessary that just the user root with a running and accessible X can register the modules? This prevents SuSE from shipping packages which run out of the box because our buildsystems don't have a X server running and we cannot access X at installation time. That means that all we can do is sending root a mail to beg him for starting mozilla once from X to make it usable by users. Fixes for this problem would be either a switch which just starts mozilla to register the modules wihtout any X access or a registry in the homedir of each user who wants to use mozilla.

I swear this is reported. I will find it.

Asa: check Suresh's comments on bug 33344, also bug 43512 (marked fixed.) Perhaps these are really separate issues.

Hi Daniel. I have filed several bugs related to this. Bug 41057 and it's dependencies (Mozilla should not need write access to the binary directory) is concerned with runtime problems with this. Bug 42148 (Mozilla-bin must not write to bin dir during installation) is about creating a small utility to overcome this problem. But I agree there is probably a better way. I'm going to confirm this and leave it open for now. An idea: Why not have each user register the modules and do all the necessary writing to ~/.mozilla/ instead of the binary directory. This is going to be a big problem for distributions as you said. I heard that Debian has a really weird install script (it doesn't work) that tries to do this.

Adding Ben and the other Netscape Daniel to cc.

Oops, forgot to confirm it.

*** Bug 48129 has been marked as a duplicate of this bug. ***

*** Bug 49023 has been marked as a duplicate of this bug. ***

*** Bug 49023 has been marked as a duplicate of this bug. ***

David, I wouldn't have a problem with the registry being written to the home directory, but at the moment it's 300KB big which is far too much. There are multiuser systems with 10MB quota and the users would still like to run a webbrowser without sacrifying at least 3% of their space for a registry. I'd like that registry program approach a lot more. Or better: The current mozilla can register the modules when run as root. That's good since we can just run it after the installation. The REAL problem is the userinterface which can't register itself without an accessible X system, that should be fixed IMHO... I'll have a look into the Gtk one whether I can do that....

egger, what exactly is your request? IMO, this is a dup of bug bug 42148.

I meant bug 42184.

Yes, I think it is. Marking DUP. Reopen, if necessary. ------- Additional Comments From dveditz@netscape.com 2000-08-11 17:14 ------- If you want a non-gui way of creating all the necessary files you can currently run "mozilla -CreateProfile" which will do all the necessary registrations, create a default profile and exit. *** This bug has been marked as a duplicate of 42184 ***

I'm searching for a way to pack mozilla on a distribution without having to tell the admin: "Please run this beast as root because otherwise your users can't use it".

Then try "mozilla -CreateProfile" (see above). It sounds as if it does just what you want.

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.

Yes..verified as a dup