Should 9.3 carry a warning about NEW_XORG

Adrian Chadd adrian at freebsd.org
Mon Jul 7 16:39:07 UTC 2014


On 7 July 2014 02:58, John Marshall <john.marshall at riverwillow.com.au> wrote:
> On Sat, 05 Jul 2014, 11:46 -0700, Adrian Chadd wrote:
>> The TL;DR reason for going up to building with new-xorg is because
>> without it, an increasing number of X related ports plainly won't
>> build anymore. They assume the newer X and DRI libraries.
>
> Thank you for this explanation: it helps.
>
>> So the choice is (a) new_xorg and pain, (b) no new_xorg and a lot of X
>> packages not getting upgraded any further, (c) more work on the ports
>> maintainers to try and figure out ways to work around an increasingly
>> impossible situation. There's also (d) - don't bother with 9.3.
>
> and (e) add WITHOUT_NEW_XORG to make.conf and upgrade to 9.3;
> understanding that this really is the end of the road for X on older
> hardware.  9.2 is EOL in a couple of months, so upgrading to 9.3 without
> breaking X makes sense to me.

Right - but once that knob goes away (because there's only new-xorg)
then they'll start updating packages to the latest upstream releases
and they may not even compile on your pre-new-Xorg. That will pull in
versions of the DRI libraries that won't work.

So it's not just going to break your Xorg compilation - it's just
plainly not going to work.

>> The X ports team has a fast moving target to keep track of and we're
>> still not anywhere near the bleeding edge of Linux graphics rendering
>> support and all the graphics stuff that moves with it. As much as I
>> hate to see lots of churn, it's a losing battle.
>
> Again, thanks for explaining the X-related development/upgrade dilemma.
> The reason for my OP was that bad things happened, unexpectedly, with NO
> warning or explanation.

Oh, absolutely. I think some of us are just .. not good at
communicating technology changes. :)

I kinda wished that the Xorg development wouldn't break older graphics
rendering so hard, but alas, what drives that is the hardware
innovation cycle and not the "holy shit you mean we need to use this
for 10 years?" cycle.


-a


More information about the freebsd-stable mailing list