xorg package set update for lts

[Maarten Lankhorst]

Hey,

Could the xorg package set be updated to include the following packages, for the lts point release?

libdrm-lts-quantal
mesa-lts-quantal
xorg-server-lts-quantal
xorg-lts-quantal

and a wildcard xf86-*-lts-quantal xserver-xorg-*-lts-quantal

same with s/quantal/raring/ would be nice too, but probably overboard at this point. :-)

----

Lets get more into details now, since I think most technical issues have been worked out now, so
I think this can be uploaded soon after verifying it works locally.

Needs to be updated in precise, for building:
 apt, for switching stacks https://launchpad.net/bugs/1062503
 x11proto-gl, from quantal for xserver
 x11proto-dri2, from quantal for xserver
 x11proto-randr, from quantal for xserver
 wayland, from quantal for mesa 9.

New unrenamed packages for precise:
 llvm-3.1, from version from quantal, used by mesa 9.

-----

All the -lts-quantal packages are autogenerated, by running the lts-stack script from:

https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools

Currently I use 'lts-stack' on quantal to download all packages, and rerun it again on
precise from same directory to generate the binaries.

Special cases:

libdrm -> weird case to rename, really special case, see lts-libdrm-rename
 all sonames have been renamed to start with libkms_ltsq or libdrm_ltsq, for example
 libdrm_ltsq_radeon.so.1 and libdrm_ltsq.so.2.
 libdrm_nouveau1a has been killed by the rename script.

mesa -> slightly easier, can no longer directly link with -ldrm* so scripts are used
 to fix those makefiles up. libosmesa6 and libgl1-mesa-dri-experimental are not rebuilt
 by the rename script.

xorg-server -> renamed, not building xdmx, xdmx-tools, xnest, xvfb, xserver-xephyr, xserver-xfbdev
 some patchups required to handle this.  A patch is reintroduced to support -nr as alias for
 -background none, as compatibility for *dm that still pass -nr in precise.

xserver-common rename is a special case, and the renamed package depends on the unrenamed
 xserver-common. The renamed package will not build the manpage, and divert
 /usr/lib/xorg/protocol.txt from the unrenamed package so there are no conflicts.

xserver-xorg-video-qxl is not built any more, it required a newer libspice-dev or something..

The drivers are all renamed through the generic script, and only xserver-xorg-video-intel
required a small fix where it used -ldrm_intel instead of @DRMINTEL_LIBS@ in one of the
Makefiles.

I think some input drivers are not built currently, but could probably easily be added if needed.

xorg renamed has its own script, I killed a lot of packages there causing troubles, and only
use it as base for defining the renamed x stack.
- xserver-xorg-lts-quantal is the core package, it has some conflicts with some unrenamed
  mesa and xorg-server packages to smoothen transitions and making sure you don't end up
  with a mixture between old and new stack.
- xserver-xorg-video-all and xserver-xorg-input-all renamed have an identical purpose to
  their unrenamed counterparts, but with the list from quantal.
  xserver-xorg-video-qxl is removed from the video-all list.

The unrenamed xorg package is modified as well.
The virtual 'xorg' binary package gets the version from its depends on xserver-xorg-core
removed. xserver-xorg unrenamed gets a conflicts on xorg-renamed-package, which is provided
by ALL renamed packages to allow conflicts with any other version. So installing xserver-xorg
makes sure no renamed packages are active. All packages also provide
xorg-renamed-package-lts-quantal, so future stacks could conflict on that to make sure you
don't get into situations where you have pieces of multiple stacks.

Open issues:

Binary drivers -> tricky, fglrx unfortunately dropped support for older cards, so no idea what
to do there yet. nvidia should have been updated to add versioned provides, but I'm not sure
if nvidia-common can take into account the current video abi yet when suggesting packages,
this needs more thorough investigation. Does anyone want to take up this item?

At one point plymouth needs to be tested with hardware that's not supported by the current
libdrm, and then we can see if we might need to update libdrm or not. I was thinking probably
something like haswell might break on plymouth if intel initialization fails. Does anyone have
the hardware to test this yet?

~Maarten