113144 - Linux installer should only download missing archives

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[walter sheets]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[walter sheets]

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

[alge]

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

[walter sheets]

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?

Comment 5

[alge]

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" ?

Comment 6

[Daniel Veditz [:dveditz]]

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.

Comment 7

[Daniel Veditz [:dveditz]]

Attachment: remember files we've found in the blob

Comment 8

[Samir Gehani]

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

r=sgehani

Comment 9

[Daniel Veditz [:dveditz]]

Taking this one.

Comment 10

[Darin Fisher]

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.

Comment 11

[Samir Gehani]

The CRC check appears to be done after we download the xpis:
<http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/unix/src2/nsXIEngine.cpp#343>

Comment 12

[Daniel Veditz [:dveditz]]

Fix checked in

Comment 13

[K'Trina Medina]

Verified code fix