Closed
Bug 167174
Opened 22 years ago
Closed 22 years ago
generate .autoreg for non installer builds
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: Biesinger, Assigned: timeless)
References
Details
Attachments
(1 file, 2 obsolete files)
3.38 KB,
patch
|
timeless
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
currently, the .zip versions (probably also .tar.gz, didn't check) do not include compreg.dat. this can become a problem if people upgrade mozilla by untarring/unzipping a new mozilla version over the old one, because mozilla will still use the old compreg.dat. therefore, the .zip/.tgz should include a compreg.dat.
Comment 1•22 years ago
|
||
there is talk of doing away with shipping a prebuilt component registry precisely because of this problem. Work on this should wait until that discussion is resolved.
Comment 2•22 years ago
|
||
And if someone had installed 3rd party components, then the new compreg.dat would override the installed components. I thought that we were recommending that people just run regxpcom after doing a manual install?
that's true, but their build won't work well at all. I it's better for them to temporarily lose their custom components in favor of having a working mozilla than for them to keep their custom components and have a mostly broken mozilla. either way they can run regxpcom to get everything, right? this is of course only an interim RFE, when we get the app to be smart enough to register components when it's newer than the registry, then this fix can be reverted.
Comment 4•22 years ago
|
||
That's what I'm saying...why is this even an issue? Until component detection is "fixed", running regxpcom after an install is a must. No other interim solution is going to Do The Right Thing(tm). The installer runs regxpcom for you as do the rpms iirc. If you're going to install the package manually, then you'll need to manually run the post-install steps.
from dveditz: XPInstall also creates a .autoreg file whose presence is supposed to trigger an autoreg at next start. if you *don't* delete the component registry then newer files *will* win, because it'll autoreg only the changed files. so including .autoreg (in fact, making sure it's generated during the build process -- this will work for dev builds too) is a good way to go. If the build process makes it, it'll end up in the zips. the file can be completely empty and needs to be where mozilla.exe is.
Summary: non-installer builds should include compreg.dat → builds system should generate .autoreg
Comment 6•22 years ago
|
||
Don't forget: <dveditz> oh, but you're thinking upgrades on top? <timeless> bingo <dveditz> that's a very very bad idea in any case Granrose, is your discussion still on going or should we go ahead with this proposal?
Comment 7•22 years ago
|
||
There is no question this is user error. The problem is that many users make this mistake and this ends up flooding talkback with crashes, and generates bugs that people usually try and fail to figure out and then end up on my door. I'm sure this is no small drain on peoples time, that could be easily dealt with. Also I had filed bug 158345 trying to address this problem. jband had thought of putting out an invalid/near empty xpti.dat to cause registration to occur. This fix may not be ideal, and maybe one of the others is better. But I think a simple fix now, is better than waiting for the ultimate fix later.
Comment 8•22 years ago
|
||
158345?
Comment 9•22 years ago
|
||
Oops Bug + 1 = bug 158346
Comment 10•22 years ago
|
||
*** Bug 158346 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
ccing chofmann, namachi. Number of crashes due to zipped binary over existing installed version is causing a lot of new TOP crashes. There is no way to understand these crashes and fix them.
Severity: normal → critical
Comment 12•22 years ago
|
||
in addition to (or instead of) adding a .autoreg file, we should change the zip installers so that instead of having the directory "bin", it is named <date>-bin. This will prevent users from automatically installing onto of a older version.
Comment 13•22 years ago
|
||
Isn't it as easy as sticking echo regme > $(DIST)/bin/.autoreg at the appropriate spot in mozilla/Makefile.in like the end of the default target?
Comment 14•22 years ago
|
||
We shouldn't have put talkback in the zip files to begin with, then we wouldn't be having this problem. We continue to try to make things foolproof, forgetting that is impossible because fools are so ingenious. The .autoreg idea sounds good, as long as it doesn't cause problems with the real installers.
Comment 15•22 years ago
|
||
Even if we don't ship Talkback bits with zipped releases the software will still crash due to mixed-installation problems. Additionally, the existing Talkback from the previous installation will be valid. Crashes for the mixed-installation will be pickedup by the Talkback from the existing installation and report to different build id. Without Talkback the users will be flooding the Bug system with invalid crash bugs. ".autoreg" solution with some kind of variability in the directory structure like dougt mentioned or other similiar mechanisms will greatly help.
Comment 16•22 years ago
|
||
so, lets make it happen. Leaf, Granrose can you hook fix this up in the release process? Sounds like it will greatly reduce installation related crashes! I am sure that hofmann's buying if you do. :-)
Reporter | ||
Comment 17•22 years ago
|
||
so, is this patch ok?
Assignee | ||
Comment 18•22 years ago
|
||
we shouldn't bother with changing the bin directory name. I can assure you that i would just rename the directory on disk before expanding. Not extracting unchanged files saves me time. As for packages, when I get a non zip version, i manually expand the packages instead of using the installer. The only time I use the installer is when I feel a need to file 5 new bugs in that component. uses touch (which cls says is ok, and which is already used on windows) packages the file for any other zip targets (by placing it before any []s this is ignoring by the installer packagers. packaging magic by mkaply).
Attachment #100586 -
Attachment is obsolete: true
Comment 19•22 years ago
|
||
Comment on attachment 100586 [details] [diff] [review] patch... Use a separate ruleset. .autoreg shouldn't be dependent upon the icon files. And what's wrong with touch?
Attachment #100586 -
Attachment is obsolete: false
Attachment #100586 -
Flags: needs-work+
Comment 20•22 years ago
|
||
Comment on attachment 100590 [details] [diff] [review] generate bin/.autoreg >Index: mozilla/xpinstall/packager/packages-mac >=================================================================== >+bin/.autoreg >+ On the mac it's "viewer" instead of bin. There's also a packages-static-win file to modify With those changes r=dveditz fwiw, but you still need cls's ok
Attachment #100590 -
Flags: review+
Reporter | ||
Comment 21•22 years ago
|
||
Comment on attachment 100586 [details] [diff] [review] patch... nevermind this one, timeless has a better one
Attachment #100586 -
Attachment is obsolete: true
Comment 22•22 years ago
|
||
last I checked, we only use the packages-* files for the installer, and we don't want .autoreg in the installer xpi files if we're still shipping a component.reg. the mozilla-win32-talkback.zip which is what this bug is about only zips up the dist/bin directory. as long as the file is in there, it will get included.
Assignee | ||
Comment 23•22 years ago
|
||
dveditz informed me and mkaply confirmed that the top of the packages- files are used for stripped down zip files. I haven't met them, but i take it on faith that they exist. dveditz's items fixed, and i fixed mac to use : instead of /, silly me.
Assignee: seawood → timeless
Comment 24•22 years ago
|
||
Comment on attachment 100590 [details] [diff] [review] generate bin/.autoreg r=cls on the Makefile change
Assignee | ||
Comment 25•22 years ago
|
||
Attachment #100590 -
Attachment is obsolete: true
Assignee | ||
Comment 26•22 years ago
|
||
Comment on attachment 100714 [details] [diff] [review] generate bin/.autoreg | viewer:.autoreg copying r=cls,dveditz
Attachment #100714 -
Flags: review+
Assignee | ||
Comment 27•22 years ago
|
||
seeking sr=alecf
Comment 28•22 years ago
|
||
Comment on attachment 100714 [details] [diff] [review] generate bin/.autoreg | viewer:.autoreg sr=alecf
Attachment #100714 -
Flags: superreview+
Assignee | ||
Comment 29•22 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 30•22 years ago
|
||
*** Bug 169217 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
DougTnscp: we are still crasing even with that .autoreg hack. could we just make the zip archives have a unique name. dveditz: fine by me... talk to build guys DougTnscp: okay
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 32•22 years ago
|
||
excuse me, but i have yet to hear a single person report the problem came from a zip build. I'm going to blame the installer builds until someone provides evidence to the contrary.
Assignee | ||
Comment 33•22 years ago
|
||
reclosing fixed. Every single complaint (e.g. bug 172158 comment 9) that I've encountered fingers the installer builds.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Summary: builds system should generate .autoreg → generate .autoreg for non installer builds
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•