dp is about to check into the build pre-generated component registry. The install wizards should copy this when they copy the XPCOM library, and XPISTUB should no longer all AutoReg. This should speed install startup. The core XPI script will also install this pre-generated registry to the final location.
Sean and Samir, we need to get this hooked up for beta.
Mac counterpart bug 14153 has been entered.
I think the release team already prebuilds the component registry as part of their build (at least for windows). We just have to make sure it gets installed as part of core. Adding Chris to the CC: list.
Leaf and I talked. Reassigning to Leaf.
the component registry can't be checked in, but we run it as part of the build process (generating it). The problem is that we can't use the component.reg that gets built in the build tree, because it has registered stuff like mailnews and editor components, which won't be in core, and will lead to errors. So i'm going to have to play with the automation in order to generate a component.reg that fits only the dlls that are included in `core.xpi'
Why can't we just use the complete one? People will ask for a component and we won't be able to load it. They have to check for that failure whether the component isn't registered, or it's registered but not found. If we ship a partial one the we have to run AutoReg anyway when people select Mail/News, in which case this is pointless and doesn't save anything.
Dan, try running apprunner after you've built the full component.reg and removed some of the editor/mail dlls in components. You'll get a bunch of dll-not found errors. If this *shouldn't* be happening, get dp to fix it. It makes more sense to me to ship a registry that matches the core components with no ``dll not found'' errors, and incrementally update the registry as we add new dlls. I thought apprunner registered new components... does it not?
Well if people add on components, then the std procedure is autoreg invoked by apprunner or by the installer. Mailnews added to the std install will fall under this category. Dan, although we have to deal with error, it is wrong for us to ship a component registry that doesn't match the package.
Leaf, if you're getting "DLL not found" modal dialogs then it's NOT a registry problem -- you removed a .DLL that was hard-linked from another one which you *didn't* remove, and the OS is giving the error. We cannot in any case package up an install in that configuration. Either file bugs on the unclean component separation, or it's user error on your part not removing an entire "package" cleanly. DP, there is no way to ship a component registry that matches all possible install combinations, and I thought part of the reason of shipping this was to avoid AutoReg. If we're going to have to AutoReg *anyway* then why bother? I suppose a Nav-only component registry will speed the install wizard itself, so that alone might make it worth producing. For the beta XPInstall isn't preserving timestamps on the files (sorry, no time), so I think AutoReg is going to get triggered anyway.
i didn't say dialogs; i was referring to text messages on the console when apprunner runs (but i guess this is just debugging info, sorry for not being more specific). I'll just wrap up the component.reg i produce in the tree; this will get the installer stuff ssu is waiting on unblocked.
Dan, what about the case of people going to Netcenter and directly running .xpi installer files? Are they going to be autoreg'ed?
We have to register new components, yes.
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
we generate component.reg before packaging.
Updating component from Install Wizard to Installer
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.