Installer needs to be carbonized



17 years ago
14 years ago


(Reporter: mikepinkerton, Assigned: slogan)


Mac OS X

Firefox Tracking Flags

(Not tracked)



(2 attachments)



17 years ago
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...


Comment 1

17 years ago
this is so a beta blocker for osx.
Whiteboard: OSX++, PDT+

Comment 2

17 years ago
sfraser is jumping on the grenade.
Assignee: ssu → sfraser

Comment 3

17 years ago
Carbonation is what you do to high fructose corn syrup.
Summary: Installer needs to be carbonated → Installer needs to be carbonized

Comment 4

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


17 years ago
QA Contact: gemal → gbush

Comment 5

17 years ago
Created attachment 41471 [details] [diff] [review]
In-progress xpinstall/wizard/mac diffs

Comment 6

17 years ago
Created attachment 41473 [details]
CarbonHelpers.h header file

Comment 7

17 years ago
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 

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

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 
Assignee: sfraser → sdagley

Comment 8

17 years ago
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

17 years ago
Clearing PDT+ and Blocker severity.  We can live without the installer for the 
beta stage of the X version
Severity: blocker → major
Whiteboard: OSX++, PDT+ → OSX++

Comment 10

17 years ago
Added kw: nsenterprise+. Priority: P1, and Target milestone: Mozilla0.9.4
Keywords: nsenterprise+
Priority: -- → P1
Target Milestone: --- → mozilla0.9.4


17 years ago
Blocks: 88116


17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 11

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

Comment 12

17 years ago
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.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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

17 years ago
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 
Keywords: nsbranch

Comment 15

17 years ago
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

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

Comment 17

17 years ago
That bug is 100168 - I'm working on it

Comment 18

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

Why is this targeted for 0.9.6???
Keywords: nsbranch → nsbranch+

Comment 19

17 years ago
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 
Keywords: nsbranch+, nsenterprise+
Priority: P1 → P3
Whiteboard: OSX++ → OSX
Target Milestone: mozilla0.9.6 → Future

Comment 20

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
This bug might be in need of closing as WONTFIX but I'm tossing it to Syd to
make that determination.
Assignee: sdagley → syd

Comment 24

17 years ago
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

17 years ago
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

17 years ago
Closing as WONTFIX since we have settled the issue of the OS X installer
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Whiteboard: OSX

Comment 27

17 years ago
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.