Closed Bug 90879 Opened 23 years ago Closed 15 years ago

make dist doesn't work due to missing files in packages-unix

Categories

(SeaMonkey :: Installer, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: BenB, Assigned: BenB)

Details

(Whiteboard: Waiting for review/feedback)

Attachments

(1 file, 1 obsolete file)

(Unix)

Reproduction:
1. Build Mozilla as userA
2. Do the install trick (regxpcom, regchrome, touch user-[skin|locale]s.rdf)
3. make dist in xpinstall/packager to create a tarball package
4. Extract that package as userB. Do not run any Mozilla binaries.
5. Try to run Mozilla as userC.

Actual result:
Crash at startup

Expected result:
works

Additional Comments:
A similar bug might exist for Windows NT.

Fix:
I have a fix, a few files were missing in packages-unix.

Weren't there some discussion about including component.reg et al in the
installer builds? ccing a few people who might object or at least know about the
discussion.
QA Contact: gemal → gbush
Attached patch Proposed fix, version 1 (obsolete) — Splinter Review
Could somebody please review?
Keywords: review
Whiteboard: Waiting for review/feedback
can you attach your fix as a patch, please? 

The installer team felt that installers felt that generating a component.reg at 
the time of installation made more sense than including a component.reg created 
at build time. I'm sure that at least part of the reason is so that 
component.reg doesn't include information about components that aren't actually 
installed. I'm happy with their decision, and i think we pre-generate component. 
reg for the non-installer packages (.zip, .tar.gz, .sea.bin)
Summary: make dist doesn't work sue to missing files in packages-unix → make dist doesn't work due to missing files in packages-unix
leaf, oh that was a mistake. Will attach the patch.

> I'm sure that at least part of the reason is so that 
> component.reg doesn't include information about components that aren't actually 
> installed.
Yes, I remember that agument now. A larger component.reg takes more RAM during
runtime, IIRC.

> I'm happy with their decision, and i think we pre-generate component. 
> reg for the non-installer packages (.zip, .tar.gz, .sea.bin)

Yes, it makes sense for tarballs to include the component.reg.

For Beonex Communicator, I create tarballs (at least on Unix), but use
packages-* files to collect only the necessary files, in order to keep the
download size to a minimum. (mozilla.org just zips up dist/bin, which contains
more files.) So, I added the make dist target to xpinstall/package to do just that.

This bug practically fixes bug 42184. With this bug fixed, installation is easy
and safe.

Any suggestions what to do?
we can't have the generated files as part of the main installer package lists. 
I see two alternate solutions depending on which way you want to go.

Option 1) A second package list. This is the technique Netscape uses to create 
Netscape 6 -- we run the Mozilla package list on the Mozilla tree, and then run 
pkgcpy.pl a second time on a Netscape list which adds the proprietary files and 
deletes some Mozilla files we don't want. This could be the first step in your 
"dist" target, for example, to copy the files generated in the step before.

2) Split 3 into 3a and 3b, then reverse the order of steps 2 and 3a -- copy all 
the files to a new location using the package lists first, *then* generate the 
registry/chrome files in the new place, then tarball the result. You could even 
make the xpinstall/packager dist do all the step 2 tasks, that would be 
*really* useful for repackagers.
I would recommend option 2 since it means no additional files checked into the
tree and by putting the process in the makefile it makes it easy to figure out
what's going on and why.  reducing confusion is good.
dveditz, it's not clear to me, what your 3 steps are.

Another idea: Add a new "package" to packages-*, like "dynamic files". It
wouldn't have to be listed in config.it (IIRC), which would cause the installer
to skip it. make dist currently grabs all packages listed in the file, so it
"dynamic files" package would be included.
I'd recommend against another target in the packages-unix file since any target
there generates and delivers a xpi file for that target.  I don't want to have
unused xpi files laying around, it doesn't play well with the existing
automation and will generate confuse rather than reduce it.
Attachment #42390 - Attachment is obsolete: true
Product: Browser → Seamonkey
QA Contact: agracebush → general
Linux installer has been discontinued on Trunk => INVALID
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
WORKSFORME
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.