Closed Bug 169602 Opened 18 years ago Closed 16 years ago
Use compressed disk image instead of gzip'd dmg for installer
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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 18 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
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.
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.
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: 18 years ago → 16 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.