Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/06, Daniel J. Luke wrote:
[...]
>> If installing software by hand
>> results in more current and more secure software for my development
>> machine, I don't get the point of using MacPorts in the first place.
>
>MacPorts provides a way to save the 'recipe' for installing software (and a handy way to uninstall/upgrade software). If it doesn't provide value for you, you probably shouldn't use it (and/or if you have ideas for making it more useful, we're always happy to have more contributors).

Exactly my point. I'd like to help out but at the same time voice my
dissatisfaction with certain conditions instead of quietly dropping it
and moving on. I love MacPorts and I care about it, that's why I bothered
to sign up for the mailing list and post this message in the first place.
Rainer did get it perfectly right in his response. [1]

>> It pains me to say that Homebrew is running circles around MacPorts in
>> the department of current available packages.
>
>[citation needed] ;-)

Gladly. I have written a small script to check that. Here are a few of
the results (of some tools I work with/run on a daily basis):

ghc
MacPorts version: 7.8.3_4
Homebrew version: 8.0.1

fontforge
MacPorts version: 20120731_3
Homebrew version: 20161001

pandoc
MacPorts version: 1.12.4.2_1
Homebrew version: 1.17.2

boost
MacPorts version: 1.59.0_2
Homebrew version: 1.62.0

fdupes
MacPorts version: 1.51
Homebrew version: 1.6.1

imapsync
MacPorts version: 1.684
Homebrew version: 1.727

mutt
MacPorts version: 1.6.0_1
Homebrew version: 1.7.0

notmuch
MacPorts version: 0.22.2
Homebrew version: 0.23

sqlmap
MacPorts version: 0.9_1
Homebrew version: 1.0.10

While the latter examples are just minor differences, especially things
like ghc, fontforge an pandoc are either completely broken and/or
severely outdated. I'm not trying to badmouth anyone or anything, just
pointing to the higher (successful) update rate in Homebrew.

>> If time and manpower is the problem, wouldn't it be better to move to a
>> GitHub-based approach like Homebrew does?
>
>That doesn't necessarily fix the problem. It's worth noting that there already is a plan to transition to github.

Why is that? Also: what do you think the problem actually is and how to
rectify it? I'd be very interested to hear that.

>> This way far more people would
>> contribute.
>
>hopefully that's true, but there's no evidence to support that assertion at this time.

Comparing the contribution rate of Homebrew to that of MacPorts, it
certainly wouldn't hurt things. On the contrary. Plus, you are just
stating the obvious: something has not been done in an exact way,
therefore there is no evidence that this exact way yields this exact
result. Duh.

[...]

[1]:
https://lists.macosforge.org/pipermail/macports-dev/2016-October/033941.html