Removal of legacy X.Org (aka non-WITH_NEW_XORG)

[Chris H]

> Hi,
>
> As you may know, the ports tree currently provides two versions of the
> X.Org server and related pieces of software:
>    1. xserver 1.7, Mesa 7.6 and libdrm 2.4.17
>    2. xserver 1.12, Mesa 9.1 and libdrm 2.4.52
>
> We are about to remove the older set. The primary reason is the
> maintenance cost. The Graphics team is small and it's a nightmare to
> test changes. The consequence is infrequent updates to those packages
> and, of course, way more work each time we decide to jump to a later
> version. All this time spent on keeping the legacy stack in a working
> state isn't invested on improving the current one and today's hardware
> support.
>
> The recent update to Cairo is a good example of this unsustainable
> situation: we tested what we could with the time we had and we sent a
> "Call for testers" on freebsd-x11@ and freebsd-current@ mailing-lists as
> well as asking for help on several Quarterly Status Reports. The benefit
> (if not the requirement) of the update and the lack of failure reports
> were instrumental in the final decision. Unfortunately, many users of
> the old X.Org server on Intel GPUs are now having crashes with any Gtk+
> applications or the X.Org server itself. This time, we won't revert
> anything or spend more time on trying to fix the old stack.
>
> Now, what does it change for the community? What are the benefits of
> this solution?
>
>     1. No more headache with WITH_NEW_XORG, alternate pkg(8) repository,
>        mismatching ABI versions between xf86-input-* and xserver.
>     2. More frequent and independant updates (ie. no need to update the
>        whole stack in one pass).
>     3. KDE and, in the near future, GNOME 3 available as packages in the
>        main repository and on install medias.
>
> Great, but what does it break?
>
> The only regression is for users of Intel GPUs and FreeBSD 8.x and
> 9.0. Those versions of FreeBSD lack the required kernel driver and
> therefore xf86-video-intel won't work (the last UMS-aware version
> doesn't work with xserver 1.12). Users can still use xf86-video-vesa if
> they can't/don't want to update their FreeBSD workstation. To install
> xf86-video-vesa, run:
>     pkg install xf86-video-vesa
> or
>     portmaster x11-drivers/xf86-video-vesa
>
> There won't be any regression for owners of Radeon GPUs because
> xf86-video-ati 6.14.6 (the last one with UMS support, which fortunately
> works with xserver 1.12) is provided as a separate port. To install this
> UMS driver:
>     pkg install xf86-video-ati-ums
> or
>     portmaster x11-drivers/xf86-video-ati-ums
>
> In the longer term, we suggest you update to FreeBSD 10.x (10.1-RELEASE
> is around the corner). For example, you can find instructions to update
> to 10.0-RELEASE here:
>     https://www.freebsd.org/releases/10.0R/installation.html
>
> Note that there's a know regression with syscons and kernel video
> drivers: you can't switch back to a console once an X.Org session is
> started. A new console driver called vt(4) fixes this issue while
> bringing nice features. It's available in FreeBSD 9.3-RELEASE and
> 10.1-RELEASE but isn't enabled by default. To enable it, put the
> following line in your /boot/loader.conf:
>     kern.vty=vt
Ugh. We've just spent the last 4 mos. tooling up for a migration of all our
server farms from RELENG_8 --> RELENG 9. It would have only taken 1 mos.
but for pkg(8) debacle. Now, if I understand correctly. The current release
schedule has effectively become:

RELENG_8.4: June 30, 2015 ===> October 8, 2014

RELENG_9: December 31, 2016 ===> October 8, 2014

:(

FWIW I'm looking forward to the NEW_XORG. But testing 11-CURRENT
indicates vt(4) isn't ready for prime time. Which makes it difficult
to justify it's requirement in RELENG.

Sincerely,
 disappointed.

>
> Note official packages reflecting this sitation will start building on
> Wednesday 8th of October and hit your mirrors as soon as possible for both
> quarterly branch and regular head.
>
> regards,
> Bapt on behalf on the X11 team
>
>