3 ms·

> "it's actually a proper package management solution", "homebrew is not", "its limitations started to show a long time ago", "is utterly ridiculous", "its just

by pbiggar 10y ago

> "it's actually a proper package management solution", "homebrew is not", "its limitations started to show a long time ago", "is utterly ridiculous", "its just some nonsense", "are supposed to port their software", "that's their job", "(that is not true)", "is simply laziness", "foolish and naive", "breaks down very very quickly", "is a horrible anti-pattern", "facile and stupid". I downvoted you. You assert a massive bunch of things with no evidence. A reasonable person could disagree with every single one of them (I do). While I could imagine your reasons for believing some (most?) of these, I would simply be arguing against the strawman I constructed. By providing actual evidence ("why do you believe this to be the case"), you would allow us have a constructive discussion on your points. Instead, you give us bile.

clhodapp 10y ago
Today, Homebrew does have some major shortcomings. The biggest one that comes to mind for me is the fact that it only seems to consider the dependencies of a package during its initial installation. That is, if A depends on B, installing A will trigger an install of B. However, after that, Homebrew will happily let you uninstall B (thus breaking A) without so much as a warning. Less critically, it doesn't track the fact that it only installed B for the purpose of making A work, so it can't help you clean up the left-behind-dependency cruft from the stuff you've since removed.
- mh- 10y ago
  I don't disagree with your assertion about the state of Homebrew, but I wanted to point out the `leaves` subcommand. brew leaves: Show installed formulae that are not dependencies of another installed formula. I'm not sure if it persists this state or simply calculates it on-the-fly by enumerating your installed formulae. But it does seem like the same data or functionality could be used to prevent your uninstalled-deps scenario.
  - clhodapp 10y ago
    Hmm... Interesting. I don't think that "brew leaves" truly solves the problem, though, since the list it generates will include explicitly-installed leaves in addition to no-longer-needed dependencies. It can help narrow the list of potential candidates for removal, though, which is nice.
brazzledazzle 10y ago
The wheat is mixed with the chaff. Ignoring the jabs at the author and their reasoning the odd way it uses and interacts with /usr/local is worth thinking about. Sometimes challenging conventions is good but sometimes those conventions are there for very good reasons that aren't immediately obvious.

by pbiggar 10y ago

clhodapp 10y ago

Today, Homebrew does have some major shortcomings. The biggest one that comes to mind for me is the fact that it only seems to consider the dependencies of a package during its initial installation. That is, if A depends on B, installing A will trigger an install of B. However, after that, Homebrew will happily let you uninstall B (thus breaking A) without so much as a warning. Less critically, it doesn't track the fact that it only installed B for the purpose of making A work, so it can't help you clean up the left-behind-dependency cruft from the stuff you've since removed.

mh- 10y ago
I don't disagree with your assertion about the state of Homebrew, but I wanted to point out the `leaves` subcommand. brew leaves: Show installed formulae that are not dependencies of another installed formula. I'm not sure if it persists this state or simply calculates it on-the-fly by enumerating your installed formulae. But it does seem like the same data or functionality could be used to prevent your uninstalled-deps scenario.
- clhodapp 10y ago
  Hmm... Interesting. I don't think that "brew leaves" truly solves the problem, though, since the list it generates will include explicitly-installed leaves in addition to no-longer-needed dependencies. It can help narrow the list of potential candidates for removal, though, which is nice.

brazzledazzle 10y ago

The wheat is mixed with the chaff. Ignoring the jabs at the author and their reasoning the odd way it uses and interacts with /usr/local is worth thinking about. Sometimes challenging conventions is good but sometimes those conventions are there for very good reasons that aren't immediately obvious.