89659 - Installer needs to be carbonized

Status: VERIFIED WONTFIX

(SeaMonkey :: Installer, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

The work was never done to carbonate the installer. it still links against non-
carbon libraries as well as a bunch of metrowerks libraries that i don't know if 
they're carbonated or not...

bugger.

Comment 1

[Mike Pinkerton (not reading bugmail)]

this is so a beta blocker for osx.

Comment 2

[Mike Pinkerton (not reading bugmail)]

sfraser is jumping on the grenade.

Comment 3

[Simon Fraser [no longer active]]

Carbonation is what you do to high fructose corn syrup.

Comment 4

[Steve Dagley]

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

Comment 5

[Simon Fraser [no longer active]]

Attachment: In-progress xpinstall/wizard/mac diffs

Comment 6

[Simon Fraser [no longer active]]

Attachment: CarbonHelpers.h header file

Comment 7

[Simon Fraser [no longer active]]

I attached some work-in-progress diffs that Carbonize the installer code. There 
are a lot of changes, because the installer code is very poorly factored. Not 
attached are the new prefix files for each of the 4 new targets (mozilla/netscape 
carbon/classic). We really need to rejig the targets in the project, since it 
seems that only resources differ between Netscape and Mozilla targets. Netscape 
targets should not be in this tree anyway.

To build with these changes, you also need to add CarbonLib and CarbonAccessors.o 
to the MIW.mcp project, and remove all the classic stub libs from the carbon 
taregets.

In addition, libjar.Lib incorrectly links with an MSL lib, which needs to be 
fixed.

I did find carbonized versions of GUSI on the net, but the main GUSI has not been 
carbonized yet. I got as close as having 1 link error in the carbon target with 
the carbonized GUSI.

Having seen the installer code up-close and personal, it is my strong opinion 
that this code should be thrown away, and the installer written from scratch 
using a well-establish application framework (like PowerPlant).

Since we've decided to not ship an installer for the X build, throwing back to 
sdagley.

Comment 8

[Steve Dagley]

Let me clarify simon's comment "we've decided to not ship an installer for the X 
build" - that applies to the beta release for X.  We're going to need something 
working by the time we RTM the X version

Comment 9

[Steve Dagley]

Clearing PDT+ and Blocker severity.  We can live without the installer for the 
beta stage of the X version

Comment 10

[Tiantian Kong]

Added kw: nsenterprise+. Priority: P1, and Target milestone: Mozilla0.9.4

Comment 11

[Steve Dagley]

Adding syd to cc: list since he 'owns' installer these days

Comment 12

[Tiantian Kong]

Grega agrees that we can move installer bugs out from the M0.9.5 milestone. So 
that Steve D can focus on some more urgent UI bugs for the M0.9.5.

Reason: Steve said there is a walkaround for Mac OSX user even if we do not 
provide a installer.

Comment 13

[Bill McGonigle (not currently reading bugmail; please contact directly)]

It occurs to me that an installer is largely unnecessary for Mozilla, proper,
and only supports the Netscape cruft (lovingly).  A .dmg with an .app would be
great for Mozilla.

Comment 14

[lchiang]

nominate nsbranch. I feel this is needed for a Netscape release.  What is the 
workaround as mentioned in the 9-11 comments which is acceptable to the general 
public?

Comment 15

[Steve Dagley]

The workaround is to go with a 'blob' install but one that's formatted as a 
bundled application (it packages the app and requisite files as a single icon the 
user can drag anywhere on their hard drive) inside of a compressed disk image.  
This is the format adopted by most OS X apps that don't have/need installers.

Comment 16

[Steve Dagley]

I forgot to add that jj has a seperate bug for doing the build work for the 
packaging and disk image generation

Comment 17

[J.J. Enser]

That bug is 100168 - I'm working on it

Comment 18

[Jaime Rodriguez, Jr.]

Nominating for PDT+ because this is a P1 and nsenterprise+.

Why is this targeted for 0.9.6???

Comment 19

[Steve Dagley]

Because we're not going to have it for the Mac OS X release and AFAIK this isn't 
an enterprise requirement (I should have cleared those keywords earlier).  As was 
commented on for the N6.1 preview for Mac OS X people liked the fact we had a 
simple drag installer (not realizing we had no installed at all for the OS X 
version)

Comment 20

[lchiang]

Thanks for the explanation.  Where would the end user license file/read me be
placed since we don't have an installer?  Would the user license file be
accessible to the user from the About page?  Would the readme file be available
in the Netscape folder? Thanks.

Comment 21

[Steve Dagley]

We'll still have a folder with support files, such as the Read Me and the Profile 
Manager icon where the application bundle will 'live'.  It's just the app and 
critical files/folders will be encapsulated as an application bundle so the user 
won't see the parts unless they ask to (there's a Finder option to reveal the 
contents of a bundle).

Comment 22

[J.J. Enser]

answer is "yes" to all of the above. both license and read me files will be
located next to the app (bundle) in the Nescape folder, and the EULA is also
accessible from the about page as it's always been.

Comment 23

[Steve Dagley]

This bug might be in need of closing as WONTFIX but I'm tossing it to Syd to
make that determination.

Comment 24

[strobe anarkhos]

You don't need an installer to display the EULA. You can make Disk Copy images
which won't mount unless the user agrees to a EULA (although the legal status of
such agreements is suspect regardless of which method is used). I agree with
Bill McGonigle, an installer isn't necessary and Apple's reccomended method for
distribution is a Disk Copy image with a stand-alone application which can be
dragged wherever the user wants.

Note: 0.9.5 doesn't appear to work if the app bundle is located on a volume
without write access. That's definitely a bug

Comment 25

[J.J. Enser]

Strobe: what you describe about the EULA is exactly what we're doing for Mozilla
0.9.5 and beyond. (pops up when the disk image is mounted)
Regarding your comment about the crash on startup when launched from the disk
image, this has been logged as bug 104954.

Unless we absolutely need a "modular" installer like we have on other platforms,
I think the current "drag-to-install" solution is satisfactory on MacOS X, and
we can close this bug as "wontfix".

Comment 26

[Steve Dagley]

Closing as WONTFIX since we have settled the issue of the OS X installer

Comment 27

[Grace Bush]

verified