State of X
in experimental
What happened since
last month? The video
drivers we were previously lacking were built against X
Server
1.9
, with a tiny exception: xserver-xorg-video-nouveau
. This one
is particularly annoying because the ABI is not stable, and it
requires a particular version of the kernel to be usable. The same
seems to happen with the nouveau
part of the libdrm
library. As a
consequence, I’ve demoted it from Depends
to Recommends
for the
xserver-xorg-video-all
metapackage.
The same happened to the xserver-xorg-input-wacom
driver (for the
xserver-xorg-input-all
metapackage this time), since it isn’t
maintained by debian-x@
, and since it didn’t look too bad to have it
only recommended (after all, we’re only targeting experimental
right
now).
In addition, all drivers were updated to the last upstream releases.
Bottom-line, the following is now possible on (at least) both amd64
and i386
architectures:
apt-get install -t experimental xserver-xorg
As a side note: Intel users probably want to upgrade their
libdrm-intel1
package to 2.4.22-2
(in experimental
as well),
they could run into
X.Org Bug #31443
otherwise.
Dependency handling for X packages in Debian
Previously, dependencies were quite fun:
Drivers used to provide a given virtual package:
xserver-xorg-input-$ABI
andxserver-xorg-video-$ABI
. One shall note that the ABI is evolving independently for input and video drivers, seeSET_ABI_VERSION
in server’shw/xfree86/common/xf86Module.h
for curious people.The
xserver-xorg
metapackage depended onxserver-xorg-core
(the server itself) with a minimal version, and on those virtual packages. More precisely, for example in the input case:xserver-xorg-input-all | xserver-xorg-input-$ABI
so that by default one gets everything for autodetection to work, but one can pick a specific driver instead.The drivers only depended on the server, with a minimal version as well.
So what did we do to ensure the server and drivers were all using the
same ABI? When the server was updated to a new ABI, one had to add the
previous virtual packages to Conflicts
(and keep a list of all of
them, yay!).
Needless to say, asking a package manager to upgrade at a same time
many packages (several dozens for all drivers) declaring conflicts,
especially during a mass dist-upgrade
from a stable release to the
next stable was no fun.
So what’s the current situation now?
xserver-xorg
depends on a minimal server version, and on drivers. The alternatives are now written like this:xserver-xorg-input-all | xorg-driver-input
. Notice there’s no ABI mentioned here anymore. It’s just about having the server, at least an input driver, and at least a video driver.xserver-xorg-core
now provides an input ABI and a video ABI. Inexperimental
for example:xorg-input-abi-11.0, xorg-video-abi-8.0
Drivers now depend on the ABI they were built against. For example,
xserver-xorg-input-evdev
inexperimental
depend onxorg-input-abi-11.0
So one might think everything is now fine, except there are some
conflicts still declared, to ensure one can transition from packages
using the former (bad) logic to the new state of affairs. And those
conflicts were
still causing headaches
to package managers. Fortunately, David Kalnischkies came up
with a proposal
to replace Conflicts
with Breaks
, which turned out to ease
things. Yatta!
All of that is implemented in experimental
. squeeze
is the
transition period where the metapackage stills the depends on
xserver-xorg-{input,video}-$ABI
virtual packages, but where drivers
now depend on the appropriate server ABI. (Thanks to Alexander Kurtz
for his feedback.)