[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Future of X packages in Debian

On Sun, 20 Jun 2004, Daniel Stone wrote:

> I think we can all agree here; I hope, anyway.

Yes at least i do (not wearing any hat).

> 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).

nice layout of the situation :-)

> 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.

How would you perform such a transition without packaging madness? I am
afraid that we will endup in a big mess of Conflicts: Replaces: Provides:
that we will have to support across at least one major release.
(hey just from a fast look.)


Reply to: