Linux installer should only download missing archives



16 years ago
12 years ago


(Reporter: walter sheets, Assigned: dveditz)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6+) Gecko/20011127
BuildID:    2001120206

Third day in a row now.  I get the 11-megabyte tarball and untar.
Run mozilla-installer (which used to just install) now insists on
re-downloading all the components a second time and then proceeds
to segfault at line 55: 2656.

This should be a no-brainer, guys!  Three days ago somebody
screwed up the way the tarball is put together--please fix it!

Reproducible: Always
Steps to Reproduce:
1.Untar the linux-sea edition.
2.Run ./mozilla-installer.
3.Watch it crash after re-fetching all the components needlessly.
I see this too.  This is only a problem if I select full install.  Doing a
typical install does not download anything.

The crash problem is 112831.

This bug is still a serious issue, separate from bug 112831.  We should not be
downloading for a SEA installer.

Ever confirmed: true

Comment 2

16 years ago
Okay, here's the solution:  if I delete the line
"C10=Component10" from the file config.ini the installer
works like it used to, and doesn't crash.

I should mention that I've been doing "Complete" installs
all along.

It appears that Component10 was added to config.ini about 
3-4 days ago but the corresponding file 'inspector.xpi' was
*not* included in the tarball.

Comment 3

16 years ago
As stated in bug 112831, it only tries to download .xpis if you select the
inspector. inspector.xpi is not in the tarball. So of course it goes looking for
it via FTP or whatever. Make inspector.xpi build and include it in the tarball,
and I'm pretty sure a full install will work as it always has. IMHO this is a
dupe of bug 112831.

Comment 4

16 years ago
I agree with comment #3 except to add that it seems
silly for the installer to download the *entire*
set of xpi files just because one is missing.

As to the crash problem, yes it probably is a
duplication of the earlier report.

Oh, I went looking for inspector.xpi in the
xpi directories on the ftp serveer and I don't
find it there.  Was it removed--or never there?


16 years ago
QA Contact: bugzilla → ktrina

Comment 5

16 years ago
About .xpi on FTP areas: read comment 5 of bug 112831.
And, the installer should probably just try to download the .xpi it's missing.
Should probably change the summary then, to something like "Installer should
only try to download _missing_ .xpis" ?
Looks like nsXIEngine::ExistAllXPIs() should do currComp->SetDownloaded(TRUE)
for each file that *does* exist, instead of just looking to see if any files
*don't* exist and then downloading them all.

Anyone want to try out my patch and see if it fixes things? I don't have a Linux
system I can build on at the moment but I think it'll do the trick.
Summary: mozilla-i686-pc-linux-gnu-sea.tar.gz using wrong installer!! → Linux installer should only download missing archives
Created attachment 60213 [details] [diff] [review]
remember files we've found in the blob

Comment 8

16 years ago
Comment on attachment 60213 [details] [diff] [review]
remember files we've found in the blob

Attachment #60213 - Flags: review+
Taking this one.
Assignee: syd → dveditz

Comment 10

16 years ago
Comment on attachment 60213 [details] [diff] [review]
remember files we've found in the blob

sr=darin, but what if one of the downloaded files is corrupt?  iirc, this is
handled when we start to install the files... that we'll try to redownload
corrupt files or something like that.


16 years ago
Attachment #60213 - Flags: superreview+

Comment 11

16 years ago
The CRC check appears to be done after we download the xpis:
Fix checked in
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 13

16 years ago
Verified code fix
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.