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.)
Fabio
Reply to: