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