74522 - installer should use extracted xpi file instead of local xpi when installing

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect)

Description

[Henrik Gemal]

I have the following scenario (while testing another bug):
I've extracted an mozilla-win32-installer.exe file in a empty c:\mozinst 
directory, by using the -u parameter.

I then currupted the browser.xpi file so that I get an error when starting 
setup.exe

Then I downloaded a newer mozilla-win32-installer.exe file from mozilla.org and 
put that file into the c:\mozinst directory. I didn't extract it.

Now when I start the mozilla-win32-installer.exe it still complains about an 
corrupted browser.xpi file.

When using the mozilla-win32-installer.exe shouldn't just use/test the 
extracted xpi files and not those located in the same directory as the mozilla-
win32-installer.exe file ?

Comment 1

[Sean Su]

this is as designed for CD purposes.  On a CD, we can have the self-extracting 
.exe (that does not contain any .xpi files) and the .xpi files along side it.

Comment 2

[Daniel Veditz [:dveditz]]

This also makes being able to re-use the saved downloaded archives work -- 
otherwise what would be the point of saving them?

Comment 3

[Henrik Gemal]

All you points makes no sense to me, since I talking about having a 
mozilla-win32-installer.exe that contains all the .xpi files.

Ok once again:
since I use "mozilla-win32-installer.exe" that contains all the .xpi files and 
these xpi files are extracted to temp place there's no need testing xpi files in 
the same dir as the "mozilla-win32-installer.exe" file. That was just my point.
This doesn't have anything to do with be able to run "setup.exe" and having xpi 
files in the same dir.

Comment 4

[Daniel Veditz [:dveditz]]

Maybe this should be WONTFIX instead of INVALID then. The easy workaround is 
to make sure you put the installer in a different directory if you don't want 
to use the downloaded .xpi files. Sean is moving on to the mail team and only 
has time to fix serious problems that will affect lots of people.

Comment 5

[Henrik Gemal]

So there will be no fix to the remaining installer bugs?

Comment 6

[Daniel Veditz [:dveditz]]

I didn't say that, I said he "only has time to fix serious problems that will 
affect lots of people." This bug isn't one of those.

Comment 7

[Henrik Gemal]

Ok.. cool. The installer is also 99% finished, while the mail could do with some 
help...

Comment 8

[Grace Bush]

verified invalid

Comment 9

[Jon Granrose]

reopening.

Comment 10

[Jon Granrose]

reassigning to default owner since ssu's no longer doing installer work.

Comment 11

[Henrik Gemal]

what's going on here? closing, reopening a lot of times..

Comment 12

[James Ots]

I came across this bug today - I downloaded the full installer into the same
directory where I had previously downloaded the netscape 6 stub installer - so
there were a load of xpi files in the directory as well. When I tried to install
mozilla then it installed parts of netscape 6 as well as parts of mozilla 0.9.9.
I could understand it doing this if I had used the mozilla stub installer, but
when I used the full installer it doesn't make sense (to me) to use the wrong files.

Comment 13

[Henrik Gemal]

*** Bug 127044 has been marked as a duplicate of this bug. ***

Comment 14

[Daniel Veditz [:dveditz]]

nominating... this leads to all kinds of wierdness that's generally hard to
diagnose.

Comment 15

[Henrik Gemal]

*** Bug 116536 has been marked as a duplicate of this bug. ***

Comment 16

[Sean Su]

Dan talked to me about it.  It could be a simple as a two line patch to
nsinstall.cpp

Comment 17

[Daniel Veditz [:dveditz]]

I'll take this one since I've already dug into the cause and a possible solution

Comment 18

[Daniel Veditz [:dveditz]]

Attachment: Don't automatically send -a argument to setup

Could I get an r= from curt or ssu?

Comment 19

[Daniel Veditz [:dveditz]]

Using this patch sysadmins who need the override behavior can still get it by
using the "-a <alternatepath>" option, but people who don't explicitly choose to
do this won't get messed up by accidentally having old cruft laying around.

Comment 20

[Sean Su]

Comment on attachment 75425 [details] [diff] [review]
Don't automatically send -a argument to setup

r=ssu too

Comment 21

[Daniel Veditz [:dveditz]]

nominating mozilla1.0 since this appeared to bite several people in the 0.9.9
milestone release and it's a simple, safe change.

Comment 22

[Scott MacGregor]

Comment on attachment 75425 [details] [diff] [review]
Don't automatically send -a argument to setup

sr=mscott

Comment 23

[Asa Dotzler [:asa]]

Comment on attachment 75425 [details] [diff] [review]
Don't automatically send -a argument to setup

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 24

[Daniel Veditz [:dveditz]]

Fix checked in

Comment 25

[Grace Bush]

verified on Mozilla/MachV