Closed Bug 169602 Opened 22 years ago Closed 19 years ago

Use compressed disk image instead of gzip'd dmg for installer

Categories

(Camino Graveyard :: General, enhancement)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Camino0.9

People

(Reporter: sbwoodside, Assigned: mikepinkerton)

References

(
URL
)

Details

Attachments

(1 file)

a tool for opening dmg-files
116.02 KB, application/x-gzip
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020918
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020918

Apple's disk image format supports compression. Please use a compressed disk
image instead of a gzipped disk image. This will make installation easier by
folding decompression and mounting the image into one step.

Reproducible: Always

Steps to Reproduce:
Would this really make installation easier? If the user's browser is configured
to hand gz files off to a helper app, then the helper app typically decompresses
the file and then hands the .dmg file off to DiskCopy automatically. That's
still one step as far as the user is concerned.

Of course, the thing blocking that for Chimera is the ridiculously simple bug
153387.

Another argument against using plain .dmg files is the lack of any proposed MIME
type for such files. I've seen application/x-diskcopy and
application/x-disk-copy. I imaging there should be something in the
application/vnd.apple space, but as far as I know Apple hasn't proposed anything.
Summary: [RFE] Used compressed disk image instead of gzip'd dmg for installer → Used compressed disk image instead of gzip'd dmg for installer
I think the bigger issue is that a compressed DMG is a (much) bigger than the
gzip file, and download size is critical if you want people to switch to your
browser over the one that's already on their machine. Here's a comparison of the
various ways you could compress Navigator.app:

-rw-r--r--  1 ssmart  staff  8457911 Oct 25 11:24 Chimera (Compressed).dmg
-rw-r--r--  1 ssmart  staff  7649722 Oct 25 11:23 Chimera.dmg.gz
-rw-r--r--  1 ssmart  staff  6953450 Oct 25 11:22 Chimera.dmg.bz2

The compressed DMG is almost 1MB bigger than the GZIP. If anything, we should
switch to BZIP2.
While hdiutil defaults to zlib level 1, that can be changed:

$ wget http://ftp.mozilla.org/pub/chimera/nightly/latest/Chimera.dmg.gz
$ gunzip --stdout Chimera.dmg.gz > Chimera.dmg
$ hdiutil convert Chimera.dmg -format UDZO -imagekey zlib-level=9 -o
Chimera-UDZO-9.dmg
$ du -sk Chimera*
7516    Chimera-UDZO-9.dmg
21304   Chimera.dmg
7500    Chimera.dmg.gz

With level 9, there's only a 0.2% difference between the dmg.gz and the dmg files.

Besides removing a step from the installation process, switching to a native
UDZO image would also allow remote-mounting of the image as an http URL. 'man
hdid' shows how: 

$ hdid ftp.mozilla.org/pub/chimera/nightly/latest/Chimera.dmg

But that's more of a 'nightly-build addict' feature :-).
Summary: Used compressed disk image instead of gzip'd dmg for installer → Use compressed disk image instead of gzip'd dmg for installer
Recommend WONTFIX per comment 1. .dmg.gz is a perfectly acceptable way to
deliver a file for download, and .gz has a corresponding widely used MIME type.
Re: Comment #4 From Greg Kolanek 2002-10-27 10:37

> Recommend WONTFIX per comment 1. .dmg.gz is a perfectly acceptable way to
> deliver a file for download, and .gz has a corresponding widely used MIME type.

In addition, not fixing this bug will allow for BZIP2 compressions, which is, as
far as I understood from Steve Dagley, planned for the long run.
Whiteboard: WONTFIX?
Did someone at some point say that you can actually use bzip2 when making the
disk images? I lost the thread a while ago, I think there were other bugs
discussing the same issues.
No, that's - AFAICT - not possible. What I was referring to was to compress the
disk images with BZIP2 *after* creating them as uncompressed images.
wontfix is OK with me.
Alright.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
*** Bug 242845 has been marked as a duplicate of this bug. ***
(In reply to comment #10)
> *** Bug 242845 has been marked as a duplicate of this bug. ***


Apple ships an /etc/httpd/mime.types file with this line:

application/octet-stream    bin dms lha lzh exe class so dll dmg

So is that good enough for the MIME whiners?  ;-)  Seriously, I just find that a
really thin reason to not distribute a simple DMG file.


Second, I'll add that Apple does have guidelines in the User Experience part of
the Human Interface Guidelines that specify this stuff.  In summary, it says
that drag'n'drop(TM) installation of a single application bundle is the ideal. 
If that's not possible, use a package installer.  So Firefox is a single app
bundle and does that already, so great.  More info about this is at:

http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_on_mac_os_x.html

The next step is packaging it for download.  Apple specifies that you make a
compressed DMG file and don't add any more needless, annoying encoding beyond
that.  This is discussed a bit at:

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGFirstImpressions/chapter_6_section_3.html

and more at:

http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_disk_images.html

You'll also see that this goes into internet-enabled disk images, which are
better yet.  It explains it all there, so I won't bother here.  But basically,
it leads to no intermediate files at all, you just get the application after
downloading.

I also watched one of the freebie videos from WWDC 2003 at ADC and it talked
about this a lot more (and other user experience stuff), I feel it's worth watching.


Aside from being tedious and annoying and introducing possible messups during
the process (not everyone has everything configured honky dory on their systems,
or has much of a clue what they're doing, etc.), there's also the fact that, at
least up until 10.3, Mac OS X had no non-shell built-in file archive
decompression software.  In 10.3, Finder handles ZIP files, that's all.  Not
everyone has StuffIt Expander installed.  It is an optional component, and also
some folks chuck it cuz of it's not so hot history with permissions problems and
some other bugginess.  So don't assume that everyone even has an immediately
obvious way to expand GZIP or BZIP2 files, cuz they don't all.  And the vast
majority of users don't know how to use gunzip from a shell.


Here's the best way to do this:

hdiutil create -srcfolder path-to-the-directory-enclosing-Firefox.app -volname
"Mozilla Firefox" -nouuid -gid 99 -format UDZO -imagekey zlib-level=9
firefox-0.8-mac

hdiutil internet-enable -yes firefox-0.8-mac.dmg

Change "path-to-the-directory-enclosing-Firefox.app" to be the path
to the parent directory of the Firefox.app bundle.
Marc: Note that this is a Camino bug, and has nothing to do with Firefox.
(In reply to comment #12)
> Marc: Note that this is a Camino bug, and has nothing to do with Firefox.

I apologize, my similar bug 242845 for Firefox was just closed as a duplicate of
this, so I added my comments here, but I guess I should reopen that one and put
my comments there...
Following the recent discussion of this for Firefox I'm going to be bold and
reopen this bug.

My logic is:
(i) its a more elegant solution, and avoids polluting the user's desktop with
two files, only one of which they may recognise as something they've downloaded.
(ii) the disk space/bandwidth saving is negligiable, only 26kB (0.34%) on the
latest nightly.
(iii) it opens faster and more cleanly (just one progress bar, no progress bar
that completes (for the unzip) only to be replaced by another). On my 2xG4 867
PowerMac a fully compressed dmg takes 7 seconds to open, against 12 for the
dmg.gz solution.
(iv) although pretty unlikely not to be installed, it avoids an unnecessary
dependency on Stuffit Expander.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Reconfirming this bug and reallocating to default owners.
Assignee: saari → pinkerton
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: winnie
Whiteboard: WONTFIX?
I agree with bruce that this could be a good thing to do.
Relevant manpage for hdiutil is here:

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html

It claims that "Sparse images, encrypted images, and zlib-com-zlib-compressed
images all did not exist in OS X 10.0.x but came into being with 10.1."

Since Camino requires 10.1.x, in theory, there should be no backwards
compatibility problem.
URL: http://developer.apple.com/documentat...
The folks over in bug 242845 seem to have implemented this now for trunk builds
of SeaMonkey, Thunderbird, and Firefox (well, once Firefox gets a trunk build
newer than 20 Jan, one presumes).

I obviously can't follow the patches there to see whether this is trivial or
not, but following Bruce in comment 14, this would be nice to see in Camino. 
One less step and file to deal with for everyone (esp. those of us downloading
nightlies attempting to track down regression dates :-))
Target Milestone: --- → Camino0.9
I think we should try to do this for 0.9 if we're plan to do it before 1.0.
Changing the distribution format just before 1.0 would be overly risky.
Flags: camino0.9?
This bug is already marked as an 0.9 blocker.
Flags: camino0.9? → camino0.9+
Another very good reason to do this quickly is because Tiger no longer comes
package with Stuffit by default.
i made the packaging script on boxset point to the make-diskimage script in the
tree instead of a local copy on the machine. that should fix it, though it
missed the nightly for today.

i'll leave this open in case i screwed up anything in the process.
Status: NEW → ASSIGNED
http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/latest/ is showing both
tonight's nightly (finally :-)) Camino.dmg as well as last night's Camino.dmg.gz

Does the latter need to be manually deleted from that folder?  Otherwise,
everything seems fine.  At least the mirror I got has an appropriate MIME type
set  for .dmg :-)

One-click mounting and one less file to deal with is really wonderful!
made changes to the build script. now nightlies are compressed dmgs.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → FIXED
i removed the .dmg.gz from the staging server.
There was no nightly on the 11th, and the nightly for the 12th (in the "latest"
aka http://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2005-05-12-08/ folder)
is the same exact .dmg--and Camino.app--(size/timestamp/About box, etc.) as the
nightly from the 10th.

Is something fouled up here, or are MoFo servers just having problems?
(In reply to comment #27)
> Is something fouled up here, or are MoFo servers just having problems?

AFAIK, it was the servers; they weren't showing any activity at all for about
two days.

hdiutil choked if the destination file was already there, so i put in a step to
delete it before doing the conversion. all should be ok now, i hope. we'll see
with today's (5/13) spin.
(In reply to comment #29)
> hdiutil choked if the destination file was already there, so i put in a step to
> delete it before doing the conversion.

You can also use the -ov switch with hdiutil.
the 2005051308-trunk camino build looks good --tested on OS X 10.4.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: