Closed Bug 110264 Opened 23 years ago Closed 21 years ago

Provide "browser-only" disc image along with "full" image

Categories

(SeaMonkey :: Build Config, enhancement, P3)

Product:
SeaMonkey
Component:
Build Config
Platform:
PowerPC
macOS
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: millennium, Assigned: jj.enser)

References

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5+)
Gecko/20011111
BuildID:    (not applicable)

On Mac OS X, Mozilla installation is provided via a disc image, which contains
just the Mozilla.app package and a few other support-oriented files, like
README's and such. This is a Good Thing, as it more closely follows OSX conventions.

However, for various reasons, this has also caused the OSX download's file size
to balloon, such that it is now among the largest downloads of any of the
platforms (there are a few larger downloads, such as the HP-UX one, but as of
this writing, the OSX install is still a full two megs larger than its Classic
counterpart, and six megs more than the Windows self-extracting installer).
Also, this method includes all of the Mozilla components by default, offering no
counterpart to the "minimal" option in the Installer which installs only the
Navigator and Composer components by default.

In the interest of file size, as well as restoring installation options, I
propose that a second disc image be offered, which corresponds to a "minimal
install" on other platforms.

Reproducible: Always
Steps to Reproduce:
1. Go to ftp://ftp.mozilla.org/pub/mozilla/nightly
2. Enter the directory for any nightly build.
3. Observe the file sizes of the various options.

Actual Results:  The only installation option for OSX is the .smi.bin based
install. This file is fifteen megs in size, larger than almost any other binary
install option (as of this writing, only the OSF, HP-UX, and IRIX builds were
larger).

Expected Results:  There should be two options for Mozilla/OSX: one being the
current .smi.bin install, and a "Mozilla-MacOSX-minimal" install, which
corresponds to the minimal installation.

Since this build is only supported on Mac OS X, it may also be worth considering
changing the disc image format from .smi.bin to .dmg.gz in order to cut download
size even further.
URL: (not applicable)
QA Contact: bugzilla → ktrina
i'm guessing build config, unless syd really wants this
Assignee: syd → seawood
Component: Installer → Build Config
QA Contact: ktrina → granrose
this is a good idea. --> jj
Assignee: seawood → jj
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here's another option.

pax gzip the mozilla directory and you get the contents down to 12 MB. 
Assuming the extra stuff required wrapped around this pax.gz to turn it into 
a pkg used by installer.app, you can fit it on a 13 MB disc image which 
when saved as a compressed image comes to 12.1 MB
Sample package available at http://www.haque.net/software/mozilla-
macosx-20011114.dmg.bin

12.5 MB

(note: server may be slow at times)
gzipping is not safe, because some of the files have resource forks.
But of course, gzipping a .dmg file is safe if it isn't a .smi.
Creating more work for ourselves and increasing the existing filename confusion
to save a meg or two isn't a priority.
Priority: -- → P3
Target Milestone: --- → Future
What Patrick says is that neither .dmg images not .gz compression format support
resource forks. We could use .img (classic disk image format), but we use .smi
(self mounting image) to benefit from the "popup dialog on mount" feature.
doing a .smi.gz file would strip out that very feature which lives in the .smi's
resource fork.
Bottom line: we need to stick with .smi.bin for now. Maybe switching from
MacBinarty II encoding to MacBinary III would save a bit, I'm not sure.

As to creating a separate image equivalent to a "minimal install", that's a bit
tricky because the OSX packaging process has no knowledge of which installer
module is part of minimal, recommended or full. These properties are described
in the installer's config.ini file, parsed at runtime by XPInstall code... which
we don't use on X.

The only "easy" approach I envision to work around this is to pass arguments to
the script that copies files from dist (pkgcp.pl) with the list of modules we DO
want (something like -xpcom -browser -mail -langenus -regus)
Status: NEW → ASSIGNED
granrose, the goal of this isn't "to save a meg or two", it's public perception.
Many users of the new d&d install feel like they're getting a bloated
all-inclusive package and they're put off. They want browser-only (it must be
slimmer, they think) but can't get it anymore. So they bitch and grumble, and
we've lost some of the ground we've been trying to hold on to in the mac community.

Seems like an easy way to pick up some (well needed) points with users, no? So
what if it's only a meg smaller if the user can get exactly what they want?
Untargeting for re-triage.
Target Milestone: Future → ---
Browser-only disk image would be cool.

Please, no pax/pkg. They are too dangerous for casual use. Mac OS X user are
already (rightly) afraid of them.
side note: the last 2 comments mention "browser only" option. There has never
been a browser only download for mozilla/ns6. "minimal" install currently
includes mail and other stuff, and that's the option I had in mind with the
suggestion I made yesterday.
I think Jon's points were that (1) I have other issues in my plate right now
that have a higher priority, and (2) doing 2 packages for OSX would imply to
change (once again) the file names hence confusing testers & users for a while.
my bug, my target milestone.  you want it, pink, it's yours.
Assignee: jj → pinkerton
Status: ASSIGNED → NEW
\/\/hatever.

setting it back, adding keyword to indicate suggested target milestone.
Assignee: pinkerton → jj
Keywords: mozilla1.0
Target Milestone: --- → Future
Based on the fact that there is no pref in Mozilla for using external apps for
mail/news and more requests for such I'd like to request we consider taking this
for Moz 1.0 after all.  (Since Necko knows to consult the OS settings for these
protocols when no handler is part of the Mozilla dist)
See bug #133386 for a patch that provides preference-driven support for 
using external protocol handlers.
*** Bug 146696 has been marked as a duplicate of this bug. ***
Patrick, any idea when the protocol handler patch from bug 133386 will be
checked in? Even if it doesn't connect to Internet Config, it would solve half
of the complaints in this bug. Currently using external mailto, news, etc is
deeply annoying.

The other half of this bug is perceptual -- if all that stuff is built in, then
of course it must be bloated and slow. No way to fix that without a standard
installer.

I believe the first part of jj@netscape.com's comment #8 is wrong. DMGs support
resource forks in their contents, but do not have resource forks for the DMG
file itself. If you put Mozilla in a DMG, the resource fork is preserved.
Therefore, that should not be a reason to not use .dmg.gz. 
It's been months since the external handler patch was marked resolved/verified.
Where is it?
engineer gone, wontfix.  if you want it, reopen the bug and reassign it to 
yourself.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Alternately, this bug could be considered a dupe of Firebird for OSX, since it
satisfies the same concerns.
Status: RESOLVED → VERIFIED
I was going to say, this really is obsoleted by Firebird, which pretty much answers the concerns I 
was trying to address when I posted this.

So should this really be Wontfix, or should it be Fixed?
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.