Closed Bug 27278 Opened 25 years ago Closed 25 years ago

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

Categories

(CCK Graveyard :: CCK-Installation, defect, P3)

Product:
CCK Graveyard
Component:
CCK-Installation
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bmartin, Assigned: kysmith)

Details

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\
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
I should have added install.txt to the above list of files.
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.
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.
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.
Correction to my last comments... The Shell\ directory and list of files should not get zipped into the cck.xpi file.
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.
This is fixed in the 2/15 build so resolving Fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking this Verified Fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.