Closed Bug 289465 Opened 19 years ago Closed 15 years ago

need to investigate mpkg installer format for MacOS X systems

Categories

(Firefox :: Installer, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 516362

People

(Reporter: chase, Unassigned)

Details

Firefox is currently only offered on MacOS X as a .dmg file which is the
equivalent of a compressed archive file on that platform.  We run into problems
with that format:

  * it ties our hands for what we can present to the user as the installed 
    application and requires them to do the work of copying the app to the 
    correct location on their system, something they will select arbitrarily

  * we cannot display a EULA to them and ask them to agree/disagree, then
    react accordingly

  * an installer-based app vehicle for mac will allow people to select extra
    components that they want / deselect extra components they don't want

A hope exists in the mpkg format which is what Apple uses for their Xcode
distribution.  This appears on the Xcode CD as a .mpkg file.  Their
developer.mpkg file provides an installation wizard that walks through
installing the app, first by explaining (in simple terms) the process, then by
presenting a EULA, then by copying files.  We probably need a similar solution
to round out our story on MacOS X.
Wow, this is a massive about-face. 6 months ago, and even when I discussed with
Ben a few weeks ago, drag-n-drop install was the gold standard; it's recommended
by the OSX developer guide also.
you can show an eula on a disk image and drag&drop installs are still the gold
standard. the user is free to put the app anywhere they want. we should have no
restrictions on that.
(In reply to comment #2)
> you can show an eula on a disk image and drag&drop installs are still the gold
> standard. the user is free to put the app anywhere they want. we should have no
> restrictions on that.

Installers on Windows and the Xcode example I provided allow installing
anywhere.  This just lets us know where we've installed.

Other things that hurt now:

  * We may need to be creating other ways to invoke the app like "Profile 
    Manager"

  * App update band-aids on Windows download the 4-5 MB file while having the 
    user wait for the download to complete.  To avoid a significant black eye 
    of forcing them to endure the download a second time if the user cancels 
    during the installer, we copy the installer to the desktop in the hope that
    they can run it if they need to without needing to download again.

    On Mac, we should provide a similar solution in the meantime but where do
    we put the dmg so that if the copy is cancelled or the update otherwise
    stopped, the user doesn't have to endure the 4-5 MB download all over 
    again?

    If we place the dmg on the desktop (aiming for an obvious place), how do
    we direct people to replace their old installation with the contents of the
    dmg?  The fear is that the user will end up with competing installations
    and will bounce freely between them based on which side of the bed they
    awoke.

This may be a WONTFIX, but if it is I want us to mark it as such knowing we can
do everything we want using dmgs and dmgs alone.  Otherwise, this is worth
considering.
>   * We may need to be creating other ways to invoke the app like "Profile 
>     Manager"

Not for users. They should be able to option-click to get safe mode (I own that
bug), but we should not be messing with the ordinary structure of a mac app. And
an installer doesn't solve that problem anyway.

>     If we place the dmg on the desktop (aiming for an obvious place), how do
>     we direct people to replace their old installation with the contents of 

Maybe we should fix the root problem by having xpinstall cache the XPI, instead
of majorly changing stuff. Putting a DMG or an installer in the auto-update XPI
is silly, we should work towards real install XPIs.
(In reply to comment #4)
> Putting a DMG or an installer in the auto-update XPI
> is silly,

Do not dismiss off-hand what we're using and what works *today*.  It's the one
solution we have.  I am all ears for a proposal to upgrade 1.0 - 1.0.2 users
that let's us forget we ever did XPI-wrapped installers.

> we should work towards real install XPIs.

Agreed.
QA Contact: bugzilla → installer
I believe this is now tracked in Bug 516362, let me know if it's inappropriate to close this issue — still somewhat new to Bugzilla culture. ;)

The reasons are a bit different from what's stated in this bug, but the end-result should be the same.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.