5 ms·

I switched away from MacPorts because packages I cared about were consistently out of date. For example, the MacPorts package for Pandoc is 3 year old [1][2]. T

I switched away from MacPorts because packages I cared about were consistently out of date. For example, the MacPorts package for Pandoc is 3 year old [1][2]. That's a cherry-picked example, of course, but was representative of my experience at the time, and appears to still be true. In contrast, the packages I've found on Homebrew have generally been up-to-date or close to it. Your milage will of course vary, and I suspect that more popular packages are probably updated much more aggressively. [1]: https://www.macports.org/ports.php?by=name&substr=pandoc https://www.macports.org/ports.php?by=name&substr=pandoc [2]: http://pandoc.org/releases.html#pandoc-1.12.4.2-14-may-2014 http://pandoc.org/releases.html#pandoc-1.12.4.2-14-may-2014

jonhohle 9y ago
Did you consider submitting a patch? In the past I've submitted patches and kept my own portfile in the mean time (seems quicker than replacing an entire package manager).
- eslaught 9y ago
  Honestly, no. If I were in the same position today, I would do so. I have submitted patches to Homebrew, for example. In my defense, the Homebrew project is much more upfront about user contributions, and I think that's a big part of why they get them. It's literally right on their homepage: > It's all git and ruby underneath, so hack away with the knowledge that you can easily revert your modifications and merge upstream updates. > brew edit wget # opens in $EDITOR! This does two things: (1) it demystifies the package format and makes it sound like something that's easy to get into, and (2) the presentation in general seems much more welcoming and positions the project as one which is open to contributions. In contrast, I've messed around with packaging on Debian, and my experience there was that there were much higher upfront costs to contributing, precisely because there was so much more tooling around the system. As an example of what I mean, try taking an existing Debian package (like, say, PHP), and rebuild it with different compile-time flags. It's a lot of work to figure out how to do that! I'm not in a position to say whether the ports system and MacPorts are anything like that, but I do have to wonder if (as representatives of a more traditional era of packaging) whether they suffer from some of the same burdens.

jonhohle 9y ago

Did you consider submitting a patch? In the past I've submitted patches and kept my own portfile in the mean time (seems quicker than replacing an entire package manager).

eslaught 9y ago
Honestly, no. If I were in the same position today, I would do so. I have submitted patches to Homebrew, for example. In my defense, the Homebrew project is much more upfront about user contributions, and I think that's a big part of why they get them. It's literally right on their homepage: > It's all git and ruby underneath, so hack away with the knowledge that you can easily revert your modifications and merge upstream updates. > brew edit wget # opens in $EDITOR! This does two things: (1) it demystifies the package format and makes it sound like something that's easy to get into, and (2) the presentation in general seems much more welcoming and positions the project as one which is open to contributions. In contrast, I've messed around with packaging on Debian, and my experience there was that there were much higher upfront costs to contributing, precisely because there was so much more tooling around the system. As an example of what I mean, try taking an existing Debian package (like, say, PHP), and rebuild it with different compile-time flags. It's a lot of work to figure out how to do that! I'm not in a position to say whether the ports system and MacPorts are anything like that, but I do have to wonder if (as representatives of a more traditional era of packaging) whether they suffer from some of the same burdens.