305373 - Camino .dmg name changed, smaller

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not sure if this goes here, m.o, or INVALID :-)

Suddenly the branch (Sat) and trunk (Fri) .dmg have been renamed from Camino.dmg
to camino-0.9a2.dmg (which seems wrong and breaks cb.o downloads and, I imagine,
tools like CaminoKnight).

They've also gotten 0.4/0.5 MB smaller at the same time, which seems odd.  The
difference in background image size is only 40 KB.  The actual app (branch) is 1
MB smaller.  So far I haven't noticed anything missing, but it is puzzling.

Comment 1

[Samuel Sidler (old account; do not CC)]

This is know. Mike said he was going to leave it for after the weekend. The new
build scripts are just creating disk images named more similar to the other
products. It's on the list though. ;)

Comment 2

[Mark Mentovai]

We know.  The fix is already ready to go, but it's a two-parter and the in-tree
fix and build script fix need to be coordinated.  Expect it to be done by the
middle of the coming week.

Comment 3

[Mark Mentovai]

As for the size changes, the new packager is slightly more efficient, but not
this much more.  The space reduction is realized both in the dmg file's size
itself and  in the filesystem that it contains: the "on-disk size" (but not the
total bytes) reported by the Finder for images produced with the new packager
will generally be smaller for identical sets of files.

But we're seeing something else here, and with the new graphics and license,
when all things are considered, the new images should actually be slightly
larger than the old ones.

The key difference is that the new packager is called by the same make machinery
that handles other Mozilla packaging, and it handles its own stripping before
calling the packager.  Previously, the build scripts would only strip debugging
symbols, using strip -S.  This still happens, but packager.mk follows up by
stripping local symbols as well, using strip -x -S.  I don't feel that this is a
problem for a release configuration, because we can still get useful backtraces,
but we'll discuss this in the coming week.

I also noticed one more thing: some of the results of autoRegister aren't being
packaged because they're in packager.mk's exclude list.  I see
chrome/overlays.rdf, but not chrome/chrome.rdf, components/xpti.dat, or
components/compreg.dat.  The end-user's computer will generate these files at
first run if they're not present and the application directory is writable, and
even if it's not, everything will still work without the files being written. 
However, there's one major problem: if the files weren't present at application
startup, Apple's CrashReporter dialog won't appear.  So, if Camino crashes
during the first run, or if the user runs Camino from the disk image (as two
examples), there won't be a CrashReporter.

I can fix this with yet another packager.mk override.

Comment 4

[Mark Mentovai]

Attachment: In-tree fix

This fixes the dmg name and prevents packager.mk from excluding files Camino
should keep.  The build scripts will need to be updated when this lands.

This doesn't do anything about stripping local symbols because I don't think
it's a bug (but I'll entertain other opinions).

Comment 5

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 193393 [details] [diff] [review]
In-tree fix

r=pink

Comment 6

[Mark Mentovai]

Checked in to trunk and branch (Camino-only)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

FYI, there are still old camino-0.9a2.dmg files in both of the latest folders,
whenever someone gets a chance.... :-)

Comment 8

[Mike Pinkerton (not reading bugmail)]

old files removed from latest/ and latest-1.0/ on staging server.