build: Use zip instead of dmg for macOS #18128

issue dongcarl openend this issue on February 12, 2020
  1. dongcarl commented at 4:23 pm on February 12, 2020: contributor

    Since macOS is able to to extract tarballs with a double-click, I’m wondering what people’s thoughts are on using zip instead of dmg for macOS builds.

    This will eliminate the following build dependencies:

    • native_ds_store
    • native_mac_alias

    A valid concern is one of UX, which might be worse.

    Here were the steps to installing Bitcoin in a DMG world:

    1. Double-click the DMG
    2. Drag the .app to the aliased Applications folder (with an arrow as the hint)

    tarballzip world steps:

    1. Double-click the tarballzip
    2. Drag the .app to Applications folder (no hint)

    ping @fanquake

  2. dongcarl added the label Brainstorming on Feb 12, 2020
  3. dongcarl added the label Build system on Feb 12, 2020
  4. jonasschnelli commented at 5:34 pm on February 12, 2020: contributor

    My 5cts on this:

    • Using the .zip file seems to be an approach done more and more by common software packages
    • The disk image offers a more native way to “install” an app by showing the Application folder (+ the arrow)
    • Additional, the disk image allows for branding space.

    I personally would ack a move from .dmg to zip. I don’t think we have to deal with users not knowing how to move an .app bundle form the downloads folder to the application folder.

    Additionally, it (the .zip approach) may simplify macOS app notarization.

  5. dongcarl commented at 7:27 pm on February 12, 2020: contributor

    Ah yes, a .zip might be better… From the link you posted on IRC:

    You can notarize an existing disk image, installer package, or ZIP archive containing your app.

  6. dongcarl renamed this:
    build: Use tarball instead of dmg for macOS
    build: Use zip instead of dmg for macOS
    on Feb 12, 2020
  7. ch4ot1c commented at 2:03 am on February 13, 2020: contributor

    I’d suggest to stick with the .dmg, just because some users really don’t know that .apps should go in Applications/.

    Though, your point makes sense. Zipping the .dmg isn’t a particularly good option either. Maybe include a README with ‘installation steps’ (one move) in the zipped .app?

  8. fjahr commented at 11:46 pm on February 18, 2020: contributor
    I agree with @ch4ot1c that some users may not know that the app needs to be moved to Applications/ but I think that could be solved with a clear instruction to do so next to the download link. If people don’t even read one-liner instructions then we can’t help them. I think that also has a better chance of being read than a README file in the zip, the concept of a plain text README file is pretty weird to non-programmers. And I also feel like I have seen this more lately, as @jonasschnelli says, so I think it will not be foreign to most users. So Concept ACK from me.
  9. fanquake commented at 1:12 pm on February 20, 2020: member

    Using the .zip file seems to be an approach done more and more by common software packages @jonasschnelli Can you give some examples? I had a quick look around, and Firefox, Google Chrome, Tor, VLC, Transmission, VirtualBox etc all still use a .dmg.

    I’m still not entirely sure, but could probably be convinced that the reduction in build-system complexity is worth the trade-off in “branding”. I might put those changes together as an alternative to/alongside #18151.

  10. fanquake added the label macOS on May 25, 2020
  11. fanquake commented at 12:57 pm on May 25, 2020: member
    After some more thought I think this is the way forward, and have pretty much finished up the changes required to switch to using a .zip. I’ll PR them shortly and close #18151.
  12. laanwj commented at 2:34 pm on May 25, 2020: member
    ~0 on this. I like the simplification in build system complexity, but on the other hand, .dmg is what most people expect for macOS software and as far as I know, by far most software uses that as distribution.
  13. dongcarl commented at 1:00 am on December 21, 2020: contributor
    GitHub Desktop uses zips instead of dmgs: https://desktop.github.com/
  14. bitcoin deleted a comment on Dec 21, 2020
  15. bitcoin deleted a comment on Dec 21, 2020
  16. jarolrod commented at 3:33 am on January 14, 2021: member

    my 2cnts, the move to a .zip is enticing in that we can eliminate some build dependencies. But, here are some arguments against that move:

    • .dmg is still the dominant format for distributing application on the macOS platform. It offers instant assurance that the application I just downloaded is a macOS specific application. Receiving a .zip may cast some level of doubt, as in: Did the server mess up and feed me a Windows application in a .zip
    • It sucks that Apple always chooses to do it’s own thing instead of adopting industry standards, but .dmg is still the standard and we should continue to use it for the foreseeable future since it is still what people expect.
  17. prusnak commented at 2:23 pm on January 8, 2022: contributor

    We simplified the creation of dmg in #23909 removing the half of the dependencies from the original post:

    • native_biplist
    • native_cdrkit
    • native_ds_store
    • native_libdmg-hfsplus
    • native_mac_alias
    • librsvg2-bin
    • libtiff-tools
    • imagemagick
    • fonts-tuffy

    Do we still want to consider moving from dmg to zip?

  18. fanquake commented at 4:09 am on January 11, 2022: member

    Do we still want to consider moving from dmg to zip?

    I don’t think we’ll make the move from dmg to zip yet, but I have opened another PR (#24031) which I think makes an OK tradeoff in regards to removing additional dependencies / build complexity from the macOS build.

  19. fanquake commented at 1:35 pm on August 8, 2022: member
    Updated the op to refect build changes since it was first written.
  20. fanquake commented at 4:05 pm on February 14, 2023: member
    Opened a new PR to discuss this change in #27099.
  21. fanquake referenced this in commit e9a4793b82 on Sep 20, 2023
  22. maflcko commented at 11:45 am on September 20, 2023: member
    Anything left to be done here? If yes, maybe open a new issue?
  23. maflcko closed this on Sep 20, 2023

  24. bitcoin locked this on Sep 19, 2024

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-03 15:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me