4 ms·

Has anyone tried MacPorts? It builds everything from source anyway, so there's a reasonable chance more things will work.

Wowfunhappy 6y ago
General note, MacPorts does not build everything from source anymore, and it hasn't for a while. MacPorts will try to find a precompiled binary on packages.macports.org, then fall back to building from source if a binary is not available. That said—while I don't know whether ARM actually works yet, MacPorts still supports PowerPC wherever possible, so they have a long history of managing multiple architectures. I expect they'll have a somewhat easier time with ARM as a result. Edit: MacPorts does indeed support ARM as of the latest release! https://lists.macports.org/pipermail/macports-announce/2020-November/000057.html https://lists.macports.org/pipermail/macports-announce/2020-...
teilo 6y ago
No, it has no more reasonable chance than Homebrew. Homebrew has always supported building from source. Bottles did not originally exist. All M1 Homebrew packages are presently being built from source, because there are no Apple Silicon bottles. It is the source packages that need to be updated and patched to work on Apple Silicon, and that is true whether you use MacPorts, Homebrew, or build them yourself from scratch.
- filmgirlcw 6y ago
  Exactly. I keep having to explain this to colleagues. For some stuff, it’s just going to take time. And I can also envision that certain packages might not get updated, necessitating a fork to patch them for M1. I’m interested in how homebrew and others will handle that (so official package x chooses not to patch/accept a patch for whatever reason, leading to a fork of package x with a patch applied), presumably to avoid namespace collisions/not giving the user what they want, there could be an error message that states that an ARM64 version doesn’t officially exist but links it to the fork and gives the option to install that instead. And then there could be a flag to always allow linked-replacements if an official patch doesn’t exist.
  - CamJN 6y ago
    since this is homebrew we are talking about the solution will be whatever is the most user hostile.
    - Hackbraten 6y ago
      Sorry if you have that impression. If you’re interested in a constructive discussion, feel free to give an example and tell me how you think we should handle it better in the future.
      - wl 6y ago
        You proved yourselves to be untrustworthy by opting everyone into analytics using Google and hiding the notice in lots of terminal output. You guys doubled down on that by refusing to reconsider, saying unless you were a contributor to the project, your opinion was irrelevant. Mike McQuaid's responses as a representative of the project were user hostile, all while he tried to paint himself as the victim of abuse over the matter. If you want to regain my trust, remove the analytics function, swear off such things forever, and expel Mike McQuaid from the project. But I doubt that will happen, so MacPorts it is. And I'll encourage everyone I know to use it rather than Homebrew.
        Hackbraten 6y ago
        Again, sorry you feel that way about Homebrew’s analytics. I think we’ve learned a lot from our mistakes here. If the way the analytics notice is implemented now is still a no-go for you, I can’t blame you for moving on. MacPorts is a fine package manager, too. One thing I still want to point out though: whatever we do, we do it in good faith and with the best of intentions for both our users and ourselves.
    - teilo 6y ago
      The only gripe I have ever had with Homebrew is the /usr/local "do yourself a favor" prefix, due to its collision with so many 3rd-party installers. But that's now been fixed.
- saagarjha 6y ago
  MacPorts handles multiple architectures a bit better. Of course the usual "this software doesn't compile on ARM" issues are still there.
notaplumber 6y ago
Another option might be pkgsrc, I'm sure someone's already looking at it. https://www.pkgsrc.org/ https://www.pkgsrc.org/
- sigzero 6y ago
  It's weird that in any homebrew/macports discussion I don't see much at all about pkgsrc. Is it not any good? Has issues? No "market share"?
  - kenada 6y ago
    The package selection is fairly limited. I tried it recently and was disappointed that neither neovim nor ripgrep are packaged. It also has little mindshare. I found out by accident that it was available for macOS.
    - sigzero 6y ago
      That's too bad. It looks pretty good command line wise.
westoque 6y ago
using macports wouldn't make it such that "more things will work". it's really about the applications now needing to be compiled in the ARM architecture. here are some examples: aom: https://github.com/Homebrew/homebrew-core/pull/57976 https://github.com/Homebrew/homebrew-core/pull/57976 boost: https://github.com/Homebrew/homebrew-core/pull/59257 https://github.com/Homebrew/homebrew-core/pull/59257 ... if you notice the code changes for the items above, they make changes to detect if the compile target is ARM and make the necessary changes so it would compile.
tannhaeuser 6y ago
I loved MacPorts, greatly preferred it over Brew, and used it all the time on Mac OS back then on my PowerBook and my dying Mac Mini, but doesn't Apple's notarization requirement make it impossible to compile from source to create runnable binaries?
- deleted 6y ago
  [deleted]
- armadsen 6y ago
  No. Even with Gatekeeper enabled, running binaries that you compile from source on your own machine doesn't require that they be notarized. As of Big Sur, they must be _signed_, but can be self-signed by a certificate you create locally. No need for Apple's approval in any way. I don't know what the status of supporting this new requirement in MacPorts (or Homebrew) is, but it's certainly something that can be dealt with.
  - tannhaeuser 6y ago
    Then let's hope Apple doesn't alter the deal further.
    - yoz-y 6y ago
      Why would they?
      - vetinari 6y ago
        They slowly tighten the screws with each release; by now it should be noticeable for most people.
        yoz-y 6y ago
        Yes they do. But the question is, why would they make a decision that will instantly make the machine completely unusable for a substantial portion of their clientele? Also, the portion that arguably gives MacBooks and, especially, iOS devices their value.

Wowfunhappy 6y ago

General note, MacPorts does not build everything from source anymore, and it hasn't for a while. MacPorts will try to find a precompiled binary on packages.macports.org, then fall back to building from source if a binary is not available. That said—while I don't know whether ARM actually works yet, MacPorts still supports PowerPC wherever possible, so they have a long history of managing multiple architectures. I expect they'll have a somewhat easier time with ARM as a result. Edit: MacPorts does indeed support ARM as of the latest release! https://lists.macports.org/pipermail/macports-announce/2020-November/000057.html https://lists.macports.org/pipermail/macports-announce/2020-...

teilo 6y ago

No, it has no more reasonable chance than Homebrew. Homebrew has always supported building from source. Bottles did not originally exist. All M1 Homebrew packages are presently being built from source, because there are no Apple Silicon bottles. It is the source packages that need to be updated and patched to work on Apple Silicon, and that is true whether you use MacPorts, Homebrew, or build them yourself from scratch.

filmgirlcw 6y ago
Exactly. I keep having to explain this to colleagues. For some stuff, it’s just going to take time. And I can also envision that certain packages might not get updated, necessitating a fork to patch them for M1. I’m interested in how homebrew and others will handle that (so official package x chooses not to patch/accept a patch for whatever reason, leading to a fork of package x with a patch applied), presumably to avoid namespace collisions/not giving the user what they want, there could be an error message that states that an ARM64 version doesn’t officially exist but links it to the fork and gives the option to install that instead. And then there could be a flag to always allow linked-replacements if an official patch doesn’t exist.
- CamJN 6y ago
  since this is homebrew we are talking about the solution will be whatever is the most user hostile.
  - Hackbraten 6y ago
    Sorry if you have that impression. If you’re interested in a constructive discussion, feel free to give an example and tell me how you think we should handle it better in the future.
    - wl 6y ago
      You proved yourselves to be untrustworthy by opting everyone into analytics using Google and hiding the notice in lots of terminal output. You guys doubled down on that by refusing to reconsider, saying unless you were a contributor to the project, your opinion was irrelevant. Mike McQuaid's responses as a representative of the project were user hostile, all while he tried to paint himself as the victim of abuse over the matter. If you want to regain my trust, remove the analytics function, swear off such things forever, and expel Mike McQuaid from the project. But I doubt that will happen, so MacPorts it is. And I'll encourage everyone I know to use it rather than Homebrew.
      - Hackbraten 6y ago
        Again, sorry you feel that way about Homebrew’s analytics. I think we’ve learned a lot from our mistakes here. If the way the analytics notice is implemented now is still a no-go for you, I can’t blame you for moving on. MacPorts is a fine package manager, too. One thing I still want to point out though: whatever we do, we do it in good faith and with the best of intentions for both our users and ourselves.
  - teilo 6y ago
    The only gripe I have ever had with Homebrew is the /usr/local "do yourself a favor" prefix, due to its collision with so many 3rd-party installers. But that's now been fixed.
saagarjha 6y ago
MacPorts handles multiple architectures a bit better. Of course the usual "this software doesn't compile on ARM" issues are still there.

notaplumber 6y ago

Another option might be pkgsrc, I'm sure someone's already looking at it. https://www.pkgsrc.org/ https://www.pkgsrc.org/

sigzero 6y ago
It's weird that in any homebrew/macports discussion I don't see much at all about pkgsrc. Is it not any good? Has issues? No "market share"?
- kenada 6y ago
  The package selection is fairly limited. I tried it recently and was disappointed that neither neovim nor ripgrep are packaged. It also has little mindshare. I found out by accident that it was available for macOS.
  - sigzero 6y ago
    That's too bad. It looks pretty good command line wise.

westoque 6y ago

using macports wouldn't make it such that "more things will work". it's really about the applications now needing to be compiled in the ARM architecture. here are some examples: aom: https://github.com/Homebrew/homebrew-core/pull/57976 https://github.com/Homebrew/homebrew-core/pull/57976 boost: https://github.com/Homebrew/homebrew-core/pull/59257 https://github.com/Homebrew/homebrew-core/pull/59257 ... if you notice the code changes for the items above, they make changes to detect if the compile target is ARM and make the necessary changes so it would compile.

tannhaeuser 6y ago

I loved MacPorts, greatly preferred it over Brew, and used it all the time on Mac OS back then on my PowerBook and my dying Mac Mini, but doesn't Apple's notarization requirement make it impossible to compile from source to create runnable binaries?

deleted 6y ago
[deleted]
armadsen 6y ago
No. Even with Gatekeeper enabled, running binaries that you compile from source on your own machine doesn't require that they be notarized. As of Big Sur, they must be _signed_, but can be self-signed by a certificate you create locally. No need for Apple's approval in any way. I don't know what the status of supporting this new requirement in MacPorts (or Homebrew) is, but it's certainly something that can be dealt with.
- tannhaeuser 6y ago
  Then let's hope Apple doesn't alter the deal further.
  - yoz-y 6y ago
    Why would they?
    - vetinari 6y ago
      They slowly tighten the screws with each release; by now it should be noticeable for most people.
      - yoz-y 6y ago
        Yes they do. But the question is, why would they make a decision that will instantly make the machine completely unusable for a substantial portion of their clientele? Also, the portion that arguably gives MacBooks and, especially, iOS devices their value.