4 ms·

No, it has no more reasonable chance than Homebrew. Homebrew has always supported building from source. Bottles did not originally exist. All M1 Homebrew packag

by 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.
- pilif 6y ago
  Homebrew's policy is to not apply patches that upstream doesn't accept, though I do notice that they are sometimes applying patches to the build systems themselves to patch in some of the paths to include files living deep inside the macOS SDK. Given that policy I would assume that such a package might die until somebody forks it and takes on responsibility for maintenance. Homebrew is about building and installing upstream packages, not about installing and maintaining custom forks of packages.
  - Wowfunhappy 6y ago
    It's worth noting, btw, that this is another major difference between Homebrew and MacPorts. MacPorts maintains tons of their own patches, whether to make software work at all or just to add support for older or newer OS's.
    - pilif 6y ago
      ... which is a blessing and a curse: When they are doing a good job, that's perfect because it means that some software which wouldn't run correctly now runs correctly. When they are doing a bad job, they might anger maintainers ("I didn't add this bug - this was added by macports - complain to them!"), or they might introduce additional security issues not present in the upstream package (see the Debian openssl bug from 2008) It might also mean that you're not getting the latest versions of upstream packages because adding those patches and rebasing them on top of upstream changes takes time. Being close to upstream was a selling-point of homebrew back in the days when it was just a collection of scripts to make it easier to build original source distributions of common Unix software.
      - deleted 6y ago
        [deleted]
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.

by teilo 6y ago

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.
pilif 6y ago
Homebrew's policy is to not apply patches that upstream doesn't accept, though I do notice that they are sometimes applying patches to the build systems themselves to patch in some of the paths to include files living deep inside the macOS SDK. Given that policy I would assume that such a package might die until somebody forks it and takes on responsibility for maintenance. Homebrew is about building and installing upstream packages, not about installing and maintaining custom forks of packages.
- Wowfunhappy 6y ago
  It's worth noting, btw, that this is another major difference between Homebrew and MacPorts. MacPorts maintains tons of their own patches, whether to make software work at all or just to add support for older or newer OS's.
  - pilif 6y ago
    ... which is a blessing and a curse: When they are doing a good job, that's perfect because it means that some software which wouldn't run correctly now runs correctly. When they are doing a bad job, they might anger maintainers ("I didn't add this bug - this was added by macports - complain to them!"), or they might introduce additional security issues not present in the upstream package (see the Debian openssl bug from 2008) It might also mean that you're not getting the latest versions of upstream packages because adding those patches and rebasing them on top of upstream changes takes time. Being close to upstream was a selling-point of homebrew back in the days when it was just a collection of scripts to make it easier to build original source distributions of common Unix software.
    - deleted 6y ago
      [deleted]

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.