+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