27278 - should not be zipping up shell\ in the cck core\cck.xpi

Status: VERIFIED FIXED

Description

[bmartin]

Latest NS-CCK installer build dated: 02-10-00

O/S: WinNT4.0

Steps to reproduce:
1. Download ns-cck installer .zip file and unzip it
2. View the contents of the CCKinstaller\Core\cck.xpi

Results:

The CCKInstaller\Core\cck.xpi should not contain Shell\

Comment 1

[bmartin]

Also, the following are getting installed (I'm pretty sure that the 
cckinstaller/core/cck.xpi should not contain them):

install.js
autorun.inf
launch.ini
setup.exe 

Comment 2

[bmartin]

I should have added install.txt to the above list of files.

Comment 3

[kysmith0 (gone)]

Question - we generate a cck.xpi file for both ccks (NS and Moz). Do we want 
this change to occur for both cck.xpi files, or just the one for NS branded cck? 

I guess I'm a little confused as to why the repro steps say to 1) download and 
unzip the ns-cck.zip file and then 2) look at contents of 
CCKinstaller\Core\cck.xpi...I fail to see the significance of the first step.  

Comment 4

[selmer (gone)]

Hmmm.  I'm not exactly sure why we create an XPI file for the mozilla build at 
all.  We don't do that for the Seamonkey product.  It aught to be sufficient for 
the mozilla builds to be provided as a simple zip file since we don't intend to 
ship an installer for it.  The installer work needs to stay focused on the 
commercial product.

Comment 5

[bmartin]

We're not creating a cck.xpi for the customized mozilla builds.  

The cck.xpi file that I'm talking about exists in the Core\ directory for the 
installable CCK deliverable.  It contains a shell\ directory and the files that 
I mention above.  Both the shell\ directory and list of files should get 
zipped up into the cck.xpi file.  That's all.

Comment 6

[bmartin]

Correction to my last comments... 

The Shell\ directory and list of files should not get zipped into the cck.xpi 
file.

Comment 7

[kysmith0 (gone)]

Just updated the automation script and tested the fixes and they look good. I'll 
check the files we'll generate with tomorrow's run (2/15) to make sure. 

Comment 8

[kysmith0 (gone)]

This is fixed in the 2/15 build so resolving Fixed.  

Comment 9

[bmartin]

Marking this Verified Fixed