Closed Bug 167174 Opened 22 years ago Closed 22 years ago

generate .autoreg for non installer builds

Categories

(SeaMonkey :: Build Config, defect)

x86
Windows 98
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: Biesinger, Assigned: timeless)

References

Details

Attachments

(1 file, 2 obsolete files)

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.
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.
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.
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
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?
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.
158345?
Oops Bug + 1 = bug 158346
*** Bug 158346 has been marked as a duplicate of this bug. ***
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
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.
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?
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.
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.
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. :-)
Attached patch patch... (obsolete) — Splinter Review
so, is this patch ok?
Attached patch generate bin/.autoreg (obsolete) — Splinter Review
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 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 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+
Comment on attachment 100586 [details] [diff] [review]
patch...

nevermind this one, timeless has a better one
Attachment #100586 - Attachment is obsolete: true
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.
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 on attachment 100590 [details] [diff] [review]
generate bin/.autoreg

r=cls on the Makefile change
Attachment #100590 - Attachment is obsolete: true
Comment on attachment 100714 [details] [diff] [review]
generate bin/.autoreg | viewer:.autoreg

copying r=cls,dveditz
Attachment #100714 - Flags: review+
seeking sr=alecf
Comment on attachment 100714 [details] [diff] [review]
generate bin/.autoreg | viewer:.autoreg

sr=alecf
Attachment #100714 - Flags: superreview+
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 169217 has been marked as a duplicate of this bug. ***
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 → ---
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.
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 ago22 years ago
Resolution: --- → FIXED
Summary: builds system should generate .autoreg → generate .autoreg for non installer builds
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: