Firefox package should use a different installer

[ghost]

Currently the Mozilla/Firefox/75.0 manifest is downloading a "stub" installer for Firefox, which is an installer that's really only intended to be run interactively and not in a package manager or other automation context. There are a few specific downsides to using the stub here:

1. It doesn't support running silently, that is without opening a GUI window and possibly prompting the user before continuing.
2. It doesn't support any customization of the installation.
3. It automatically selects the correct architecture to install; it doesn't necessarily install the x64 Firefox build even on an x64 OS.
4. It always installs whatever the latest version is instead of pinning to a specific one; this means that calling the package 75.0 has technically become incorrect since the manifest was created, because right now it's actually installing 75.0.1.

We (Mozilla) also package "full" installers, which do contain a specific version and architecture of Firefox, have a silent mode, and support other command-line customization options. They're a lot more like what the packages I'm seeing here for other applications use, and they're designed to be suitable for automated scenarios like package management. These can be downloaded from here, or from our archive site (the easier choice for building a URL from a script, for instance).

I don't want to send a PR right away because I'm not sure of the best approach; I'm guessing it would be a bad idea to just swap out the URL (and hash) in an existing manifest file, but since there's a newer version available already (75.0.1), could just making a new manifest for it that uses its full installer be a complete enough solution?

[mkaply]

And is there some way for us to automate this process?

[superusercode]

@mkaply The full installers are definitely ideal and should replace the existing stub listing (Chrome and Edge already use their full MSI installers). As far as I can tell, there is no way to automate updating the links on listings like chocolatey and scoop can. Due to this limitation in winget I think it would be best to add the 68.8.0 ESR alongside the current 76.0.1 installer.

[superusercode]

Additionally, I am still unsure about the best practices on writing these YAML files. The "good" and "better" examples on the Microsoft Docs page do not include the same fields as what the generator tool in the repo and in the MS Store include. I hope the developers can clarify this.

[mkaply]

Do you have a link to the complete docs? Wondering how to pass command line parameters.

[superusercode]

@mkaply
https://github.com/microsoft/winget-cli/blob/master/doc/ManifestSpecv0.1.md for the spec
https://docs.microsoft.com/en-us/windows/package-manager/package/manifest?tabs=minschema%2Ccompschema for creating packages

if your full fat installer is msi/msix or nullsoft/innosetup then you don't want to pass any switches. If it is an exe where you need to provide switches (sometimes an exe doesn't if you check your manifest with winget validate) then you will provide it like in this example

Id: Opera.Opera
Version: 68.0.3618.63
Name: Opera
Publisher: Opera
License: Copyright Opera Unite Pte. Ltd.
AppMoniker: opera
Description: Opera browser for computers
Homepage: https://www.opera.com/
Installers:
  - Arch: x86
    Url: https://get.geo.opera.com/pub/opera/desktop/68.0.3618.63/win/Opera_68.0.3618.63_Setup.exe
    Sha256: E5B4FBE94E29F0C90C297007205D5F0AB642AA10B2EBCEB038868BA4FC4D04D8
    InstallerType: exe
    Switches:
      Silent: --silent
      SilentWithProgress: --silent

For some reason both are identical. I recommend the generator from https://github.com/microsoft/winget-pkgs/blob/master/Tools/YamlCreate.ps1 for getting started.

[superusercode]

in this case for 76.0.1

Id: Mozilla.Firefox
Version: 76.0.1
Name: Mozilla Firefox
Publisher: Mozilla
License: Mozilla Public License 2.0 (MPL)
LicenseUrl: https://www.mozilla.org/en-US/MPL/2.0/
AppMoniker: firefox
Description: Mozilla Firefox is free and open source software, built by a community of thousands from all over the world.
Homepage: https://www.mozilla.org/firefox/
Installers:
  - Arch: x64
    Url: https://download-installer.cdn.mozilla.net/pub/firefox/releases/76.0.1/win64/en-US/Firefox%20Setup%2076.0.1.exe
    Sha256: 9BB84318124F1335AA1EBBA2447E30643E462DDF8318F7D2B61F0B37F733BE48
    InstallerType: inno

[superusercode]

on the other hand, it looks like the ESR listing in winget uses an MSI made explicitly for enterprise use, so I don't think it needs any changes.

[superusercode]

PS C:\Users\super\Desktop\0.12> winget show Mozilla.Firefox -e
Found Firefox [Mozilla.Firefox]
Version: 76.0.1
Publisher: Mozilla
Description: Mozilla Firefox is free and open source software, built by a community of thousands from all over the world.
Homepage: https://www.mozilla.org
License: Mozilla Public License 2.0 (MPL)
License Url: https://www.mozilla.org/en-US/MPL/2.0/
Installer:
  SHA256: 07851d13b1e03e9f025f65ac616264e625819bcfeef64f333ab61df9cda2265c
  Download Url: https://download-installer.cdn.mozilla.net/pub/firefox/releases/76.0.1/win64/en-US/Firefox%20Setup%2076.0.1.msi
  Type: Msi
PS C:\Users\sacha\Desktop\0.12>

[superusercode]

This issue was closed by #1278

[denelon]

@mhowell-mozilla we would be happy to work through an automated way for Firefox to "auto-publish" PRs, or have comments added in the manifest to help user submission as versions change. The desire is to be able to support the installation of an explicit version for developer scenarios. User scenarios might benefit from a different approach, and we're happy to discuss options.

[ghost]

Thanks for the reply. To be clear, I'm totally in favor of listing individual versions as long as there's a default that always pulls the latest version, which does seem like how the CLI works here, so I don't see any issue.

I wouldn't be the one to make this decision (I'm engineering owner for the installers, but I'm not really involved in build or release engineering), but my guess is that we would not get involved in maintaining our own automation for manifest generation and submission, just as we don't tend to provide our own packages for other kinds of package managers. I'd be happy of course to give advice, or if it would help to provide a commented example manifest, I can do that.

[SoftCreatR]

I think, I've successfully automated the deployment of most FF versions (Stable, Developer & ESR) (see https://github.com/microsoft/winget-pkgs/blob/master/manifests/Mozilla/Firefox/77.0.yaml for example).

However, I need to monitor that until the next release, because sometimes, our internal routine is going crazy.