3 ms·

Why didn't you like the project if it was a better project by most definitions of what makes a good package manager? e.g. what did you want from a package manag

Why didn't you like the project if it was a better project by most definitions of what makes a good package manager? e.g. what did you want from a package manager besides 1. easy to install packages 2. readily updated packages.

larusso 2y ago
macports had the cleaner packages. Macports created its own base library so that packages are not based on the macOS system libraries which managed to break them when doing system updates with brew or when you decided to stay longer on an older macOS version. That meant that packages from macports took longer to install and compile. That was from the time when bottles where not a thing yet. Brew was fast but unstable. In my opinion the inferior project won. But to brews defence they also addressed the issues over the years. Don‘t have any sources at hand but I remember a time when the brew project compared itself to macports and pointed out that their faster because they don‘t recompile all base libraries etc etc. And they had to realize that this wasn‘t a great idea. Now packages are practically split between different os versions. And different bottles are served depending which macOS version you run. Edit: And I got reminded that it was possible to run and install packages for and from multiple users. Brew took over /usr/local/bin and other /usr/local/homebrew for the running user. Managing a system with multiple users with brew was and still is hard. With macports you needed sudo like with most other package managers. The sudo less nature was a huge deal for its adoption. And now maybe a security risk if you ask me.
- pasc1878 2y ago
  macports eventually got an infrastructure that allowed binaries to be downloaded so no need for compilation on your local machine. SO the speed issue went away but too late as Hom,ebrew had gained the mind share
sofixa 2y ago
> 1. easy to install packages 2. readily updated packages. Not OP, but I want my package manager to have good UX around package installs and updates, not it deciding to update a Python major version because a random small thing I'm installing it requests it.
dur-randir 2y ago
Their maintainers have a rather dubious anti-user history with opt-out analytics and forced auto updates to said analytics.

larusso 2y ago

macports had the cleaner packages. Macports created its own base library so that packages are not based on the macOS system libraries which managed to break them when doing system updates with brew or when you decided to stay longer on an older macOS version. That meant that packages from macports took longer to install and compile. That was from the time when bottles where not a thing yet. Brew was fast but unstable. In my opinion the inferior project won. But to brews defence they also addressed the issues over the years. Don‘t have any sources at hand but I remember a time when the brew project compared itself to macports and pointed out that their faster because they don‘t recompile all base libraries etc etc. And they had to realize that this wasn‘t a great idea. Now packages are practically split between different os versions. And different bottles are served depending which macOS version you run. Edit: And I got reminded that it was possible to run and install packages for and from multiple users. Brew took over /usr/local/bin and other /usr/local/homebrew for the running user. Managing a system with multiple users with brew was and still is hard. With macports you needed sudo like with most other package managers. The sudo less nature was a huge deal for its adoption. And now maybe a security risk if you ask me.

pasc1878 2y ago
macports eventually got an infrastructure that allowed binaries to be downloaded so no need for compilation on your local machine. SO the speed issue went away but too late as Hom,ebrew had gained the mind share

sofixa 2y ago

> 1. easy to install packages 2. readily updated packages. Not OP, but I want my package manager to have good UX around package installs and updates, not it deciding to update a Python major version because a random small thing I'm installing it requests it.

dur-randir 2y ago

Their maintainers have a rather dubious anti-user history with opt-out analytics and forced auto updates to said analytics.