On Fri, Jun 18, 2004 at 09:02:50AM +0200, Fabio Massimo Di Nitto wrote:
> As you might have seen from the messages on debian-devel-changes,
> 4.3.0.dfsg.1-5 has been accepted into unstable.
>
> As XSF release manager, I have no objections to the TODO list for -6 [0],
> but there is one item that we consider extremely important and that, in
> our opinion, requires the community attention, since it is a *hot*
> argument that many other distributions have already faced [1][2] or are
> facing now.
>
> (reason for the cross posting and set your follow-up to debian-x please)
>
> * Add FAQ entry describing Debian's plans in the X department.
>
> We all know by now that due to several licensing-related issues we cannot
> keep using XFree86 as our primary upstream source for an X Window System
> distribution [3]. But we need a clear plan before we can add a FAQ entry
> describing our plans. Some XSF memebers have already expressed their
> opinion on what the future of X in Debian should be.
>
> Our questions to the community are:
I've put a couple of short answers below, with a longer spiel under
that.
> * What kinds of X packages would you like to see in the future?
Modular, but that's not achievable now.
> * Should we regard X.Org or FreeDesktop.Org as our upstream source?
Both.
> * Should we go our own way starting from the "sanitized" XFree86 CVS
> snapshot we've prepared?
No.
> * Should we ensure that multiple implementations of the X Window System
> are packaged, or standardize on just one?
If there's merit, sure. If it's unnecessary and will just cause pain,
no. Make it optional, but don't do it just for the sake of it.
> * If we standardize on just one, which one should it be?
An X server approximating the one from X11R6.7, no matter which build
system.
Let's start out with an unemotional dissection of the facts:
* XFree86 has a licence we cannot work with.
* The monloithic tree is very, very large; updating to major
releases is a great deal of effort, and you must be careful
about what you upload. Needing to maintain a platform's
details in imake makes things difficult - it duplicates work.
Ditto the MetroLink loader; this goes for both XFree86 and
Xorg.
* The modular tree, as it stands, is not quite ready for
adoption yet[0]. We have not yet worked out how to achieve
XFree86-ELF<->libdl binary compatibility (or not really tried,
either way), and porting of extensions is still not finalised.
However, the libraries are fine.
* KDrive does not offer the maturity and driver support Debian
needs; it also doesn't do stuff like DRI yet.
I think we can all agree here; I hope, anyway.
I personally have an affinity for the modular tree, as it solves many
problems; my bias here being that I'm a (currently, paid) developer on
it.
Here are the possibilities:
Libs:
* fd.o - needs libX11 merged, and a couple more client-side
libs. Other than that, fine. Uses autotools; one module per
library/extension.
* X.Org - monolithic tree with imake. IPv6 support.
* XFree86 - monolithic tree with imake.
Server:
* X.Org - monolithic tree with imake. IPv6 support. DRI tree
merged in CVS.
* XFree86 - monolithic tree with imake.
* debrix - modular tree with autotools, comes from X.Org tree.
No GL support as yet (that part of the world is particularly
nasty WRT imake hackage).
Apps:
* X.Org/XFree86 - monolithic tree with imake.
* fd.o - modular tree with autotools; not that many apps merged
yet.
Fonts:
* X.Org/XFree86 - monolithic tree with imake.
Docs:
* X.Org/XFree86 - monolithic tree with imake.
As can be seen here, the operational word for modular is 'not there
yet'. The libX11 changes made in X.Org in the run-up to R6.7 still need
to be merged (I'm hoping to get to that this weekend), and it still
needs a few libs, such as libXvMC, but is rounding out very quickly.
Most libs are relatively trivial to add.
Fonts and docs are a clear decision: the monolithic tree is the only
provider of these. Despite best intentions (and efforts), most apps are
still only available in the monolithic tree.
The server arena is where it gets interesting - it's where we have the
most to gain, but the most to lose. debrix is a quite ambitious
proof-of-concept, aiming to prove three concepts:
a) modular builds for servers work (proved),
b) dlloader works/can be made to work (proved),
c) out-of-tree builds for drivers work (proved).
Right now it builds a working ATI driver (out-of-tree) with working
acceleration, but there are a couple of unavoidable ABI (and API)
changes[1], which means no nvidia_drv.o, and no fglrx. It also hasn't
had most of the drivers ported over to the new modular infrastructure,
so strike on that count. No DRI, either. It's pretty ambitious, and will
need a little more time yet.
That being said, I think debrix is firmly in Debian's future. The
ability to have separate driver modules, and out-of-tree builds for
everything, will mean a whole lot less pain. I am firmly convinced that
modularisation is the only path that will lead us all to less pain: less
pain for users with low bandwidth (says the dialup user), less pain for
us as we struggle with massive source packages, and less pain for
everyone with major updates. There's no reason to be updating docs and
fonts as often as drivers - the release schedules are naturally
disconnected, and the monolithic is an abitrary (and, IMO, wrong)
connection of these.
One example here is the DRI tree (now merged into X.Org), which now has
i915 support. A chipset that hasn't even been released. If this were the
modular tree, I could package it up in half an hour (if that), and
upload it, and wham, we'd be supporting this stuff before it hit the
market. Contrast this with i845 (which I still regard as a huge personal
failure), where we took over a year after one of the most popular
integrated cards came on to the market and flooded in through Dell and
other major cheap-PC makers, to even have support in experimental.
It also allows us to be far more rapid and timely in our updates, as
modifying small areas of X hurts far less than casting a massive swathe
across docs, fonts, servers, libs, and apps. It also means that we don't
get 4.2/4.3 situations, where the update to the whole tree is such a
massive burden that it takes us ages to get it done. It means that X in
Debian becomes less scary: it's far easier for others to join in and
help[2].
However, my enthusiasm for the modular tree is tempered by some parts of
it not existing. Putting docs and fonts firmly in the realm of the
monolithic tree for the time being, assuming that debrix will not bear
fruition for a month or more yet (then you have to wait for nVidia and
ATI to rebuild their drivers against it, which is an arbitrary delay),
if we were to talk about the short-term future of X, there is currently
only one major area to talk about - libraries.
I believe that fd.o libraries are a good transition point, as well as a
good test of our flexibility in X. fd.o is also a far more forgiving
upstream (myself, keithp, wt, et al) - so it can be a good point to
start patchbombing and getting rid of our liabilities in that sense.
We could also start the slow app migration, and autotool missing apps as
we go; for the time being, just disable the ones that are there. Moving
to Thomas Dickey's xterm entirely would also be nice.
Thus, my short-term proposal is:
* Libraries: fd.o, from /cvs/xlibs, according to
http://people.debian.org/~daniels/xlibs.html.
* Server: X.Org, built from the monolithic tree.
* Apps: Mix of monolithic and some broken-out apps - gradual
migration towards modular.
* Docs/Fonts: X.Org, built from the monolithic tree.
If the DDK patches were merged, this might also significantly ease the
pain WRT drivers. My preferred long-term solution obviously involves
moving to the modular tree.
If we continue to have a single monolithic 'xorg' source package, we can
keep working from this, while in parallel working upstream on the
modularisation efforts. This provides a good solution to the problem of
slowly-drifting X implementations (the libraries are particularly
worrying), and also alleviates our workload, as we can start merging
some of our hundreds of thousands of lines of patches into the parts
we've modularised.
This means that we can disable app building one-by-one, get rid of the
fonts, docs, et al, and eventually also the server.
I am willing to expend significant work on this; indeed, I'm in the
middle of my rejuvinated xlibs work, and am prepared to put in the work
to disable the libs on the server side - all the packaging work that
would be needed to transition to using fd.o xlibs.
:) d
[0]: Check out debrix, debrix-driver-ati, debrix-input-mouse, and
debrix-input-keyboard from the xserver CVS root if you want to see
my current work on this. Right now, it builds a modular server with
out-of-tree-drivers, libdl, and all that goodness. What it won't do
is load nvidia_drv for you, or fglrx. It still has a way to go yet
- including porting the rest of hw/xorg/drivers - and thus is not
able to be considered at this point in time.
[1]: Firstly, we're building first-class shared libraries, instead of
the abortion encouraged by MetroLink. Secondly, you can't have
interdepencies with variables; all variables need to be resolved at
load time, whereas functions get lazy resolution.
[2]: Not so Joe Blow can be arsing around with driver code, but so
people will feel empowered to help with FTBFSes and packaging
problems, to submit bugs with patches, et al - so they're not
scared off X for whatever reason.
--
Daniel Stone <daniels@debian.org>
Debian: the universal operating system http://www.debian.org
Attachment:
signature.asc
Description: Digital signature