5 ms·

The majority of the ports and software I want installed are essentially Unix/Linux/GNU environment tools. Macports has always seemed to me to be a more "unix-y

by rswail 6y ago

The majority of the ports and software I want installed are essentially Unix/Linux/GNU environment tools. Macports has always seemed to me to be a more "unix-y" way of doing that, and it works politely with Apple's ways on top of the Unix core (eg locking down the system volume). It also has a very nice "select" and "variants" system that allows you to have multiple versions of a package as well as packages with more or less functionality (eg integrating with the MacOS keychain etc). When I first got into Macs (only around 5 years ago), I looked at both homebrew and macports and as soon as I saw homebrew blasting stuff into /usr/local while macports neatly put everything in /opt, I was convinced to go with macports. I also had previous experience with the BSD's port systems, which helped push me towards macports. But I'm open to being convinced about homebrew, although I've never needed something that it had that macports didnt.

ComputerGuru 6y ago
I used to recommend Homebrew but stopped some time ago (v2, perhaps?) when they hard-removed all build customization/options in order to make it easier to develop bottles and close out GitHub issues (on their end) while severely restricting what users could do, taking away a lot of power and freedom that was previously available. Much more inline with the Apple line of thinking, but that’s kind of the reason people wanted a *nix-esque package manager, no?
ihuman 6y ago
Why is it bad that homebrew puts files in /usr/local? Edit: They use /opt if you're on Apple Silicon https://github.com/Homebrew/brew/blob/master/docs/Installation.md https://github.com/Homebrew/brew/blob/master/docs/Installati...
- gregmac 6y ago
  My first experience with homebrew (as a non-mac user) was setting up a build agent a few years ago. It seemed like a nice way to get everything going, as well as being analogous to the ways it was setup on other OSes (using packages to manage the SDKs/tooling). I think my mistake was treating it like any other unix-y [multi-user] system, because I installed everything with one account, then created a dedicated 'build' account for the agent to run as -- exactly as our linux (and even, ahem, Windows) agents were setup. This caused all kinds of failures for the 'build' user as everything was owned by and had permissions setup for the first user. I came away kind of disgusted at the horrible patterns in use. Windows has spent two decades cleaning up that mistake, and here's a comparably new system making the same, awful mistakes? User-writable/owned stuff goes in ~. Period.
- joseph 6y ago
  There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.
  - mekster 6y ago
    How's the experience putting it under your home? I assume many packages need to be compiled but does everything compile fine?
    - joseph 6y ago
      I've never had an issue with it. I just add ~/brew/bin to my PATH and everything works fine.
    - saila 6y ago
      I'm upgrading right now on Big Sur, and everything was installed from pre-built binaries; nothing was compiled locally.
  - vetinari 6y ago
    It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.
    - saagarjha 6y ago
      It used to turn /usr/local into a Git repository, at least until that got locked down with SIP.
      - vetinari 6y ago
        While /usr is locked down with SIP, /usr/local is not, it is perfectly writable; brew does create new directories there and changes ownership of existing ones.
- rswail 6y ago
  /usr/local was originally for local (ie host) software that wasn't in /usr/{bin,lib,sbin,slib...} or /{bin,lib,sbin,slib...}. Then GNU took over and made some opinionated choices about how those subdirectories were to be used, which is fine. However, because /usr/local is under /usr, it meant that it was more difficult to mount /usr as read-only or shared. There is also the issue of whether files under /usr/local should be owned by non-system users. A while back, the creation of /opt and /opt/{some-app} (and /var/opt/{some-app} became a way to avoid writing into /usr and also made it possible to mount applications with their code as read only with writable locations under /var. So I've taken writing to /usr/local as a packaging smell these days, purely to avoid writing into /usr.

by rswail 6y ago

ComputerGuru 6y ago

I used to recommend Homebrew but stopped some time ago (v2, perhaps?) when they hard-removed all build customization/options in order to make it easier to develop bottles and close out GitHub issues (on their end) while severely restricting what users could do, taking away a lot of power and freedom that was previously available. Much more inline with the Apple line of thinking, but that’s kind of the reason people wanted a *nix-esque package manager, no?

ihuman 6y ago

Why is it bad that homebrew puts files in /usr/local? Edit: They use /opt if you're on Apple Silicon https://github.com/Homebrew/brew/blob/master/docs/Installation.md https://github.com/Homebrew/brew/blob/master/docs/Installati...

gregmac 6y ago
My first experience with homebrew (as a non-mac user) was setting up a build agent a few years ago. It seemed like a nice way to get everything going, as well as being analogous to the ways it was setup on other OSes (using packages to manage the SDKs/tooling). I think my mistake was treating it like any other unix-y [multi-user] system, because I installed everything with one account, then created a dedicated 'build' account for the agent to run as -- exactly as our linux (and even, ahem, Windows) agents were setup. This caused all kinds of failures for the 'build' user as everything was owned by and had permissions setup for the first user. I came away kind of disgusted at the horrible patterns in use. Windows has spent two decades cleaning up that mistake, and here's a comparably new system making the same, awful mistakes? User-writable/owned stuff goes in ~. Period.
joseph 6y ago
There's nothing wrong with installing packages into /usr/local, but brew turns /usr/local into a git repository and IMO that is wrong. Also, brew acts like it's made for a single user, as it changes files and directories to be owned by the user running it, but /usr/local is a system directory. When I install brew, I always put it into my home directory instead of /usr/local.
- mekster 6y ago
  How's the experience putting it under your home? I assume many packages need to be compiled but does everything compile fine?
  - joseph 6y ago
    I've never had an issue with it. I just add ~/brew/bin to my PATH and everything works fine.
  - saila 6y ago
    I'm upgrading right now on Big Sur, and everything was installed from pre-built binaries; nothing was compiled locally.
- vetinari 6y ago
  It turns /usr/local/Homebrew into a git repository; not /usr/local itself. Whatever it links into /usr/local/{bin,include,lib,sbin,share} is just a symlink into /usr/local/Cellar.
  - saagarjha 6y ago
    It used to turn /usr/local into a Git repository, at least until that got locked down with SIP.
    - vetinari 6y ago
      While /usr is locked down with SIP, /usr/local is not, it is perfectly writable; brew does create new directories there and changes ownership of existing ones.
rswail 6y ago
/usr/local was originally for local (ie host) software that wasn't in /usr/{bin,lib,sbin,slib...} or /{bin,lib,sbin,slib...}. Then GNU took over and made some opinionated choices about how those subdirectories were to be used, which is fine. However, because /usr/local is under /usr, it meant that it was more difficult to mount /usr as read-only or shared. There is also the issue of whether files under /usr/local should be owned by non-system users. A while back, the creation of /opt and /opt/{some-app} (and /var/opt/{some-app} became a way to avoid writing into /usr and also made it possible to mount applications with their code as read only with writable locations under /var. So I've taken writing to /usr/local as a packaging smell these days, purely to avoid writing into /usr.