+system_x11 to bite the dust
Jeremy Huddleston
jeremyhu at macports.org
Thu Apr 30 16:42:02 PDT 2009
On Apr 29, 2009, at 13:57, Marcus Calhoun-Lopez wrote:
> Isn't there a case to be made for hedging our bets?
>
> I think it's safe to say that not too long ago, the MacPorts X11
> libraries
> were a mess of broken ports and inconsistent dependencies.
> Thanks to the hard work of a select few, this is no longer the case.
> If bit rot should ever creep into X11 again, I would not have a clue
> how to fix it.
>
> Because X11 is complicated but essential, shouldn't we keep the option
> of reverting to the Apple X11?
>
> My apologies if this sounds too much like the invalid
> "no, I like not using MP's X11 libs" reason.
I'd say it's a bit more verbose and rooted than just "I like it that
way" ...
You bring up a good point, but I don't think it's as big a concern as
you might think.
If it happens that I get hired by some company tomorrow and have some
clause about not contributing to open source (they'd have to make a
*VERY* good offer for that to be the case, but let's just play the
assumption game for a while), then X11 might "bitrot", and whoever
might take my place at Apple might not want to work with MacPorts.
That would be unfortunate, but I don't think it would be as dire as
you believe. I've taken great strides to ensure that all bits are
pushed into upstream. The client side (which is what is mainly
important) is almost identical to what is used on every other
platform. The upkeep at this point is mainly just updating version
numbers in the Portfile.
The server and libGL are the more fragile points, and yeah, they may
bitrot if something horrible happens (like the scenario I mentioned
above)... but that's the risk we take with every package... and the
server isn't critical, since users can easily fall back on the Apple-
provided X11 server by just executing /A/Utilities/X11.app rather
than /A/MacPorts/X11.app
More information about the macports-dev
mailing list