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

Re: Future of X packages in Debian

On Sun, Jun 20, 2004 at 01:42:43AM +1000, Daniel Stone wrote:
> 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.

As best I can recall, it shouldn't be too much trouble to prepare a
hacked up monolithic tree that doesn't build the X servers or libraries.
I.e. client, fonts, and docs only.

XTerm, at least, should be made independent in any event.  I think you
were saying that as well.

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

You may wish to consider it evidence of a perverse and cruel God, then,
that in reward for your justified pride in getting i915 support into the
codebase before the chipset is released, Intel recalls it from the

My condolences.

> However, my enthusiasm for the modular tree is tempered by some parts of
> it not existing.

Thanks for the most quotable statement of the thread.  :)

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

I think the migration should be driven by the phenomenon of people
popping up to actually maintain such projects.  I get the feeling a lot
of the old SI clients aren't going to get much love at all.  (For a few,
like xmh, this is not really a loss, and I'd argue that one should be
shut off and discarded at the source -- if it hasn't already been.)

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

Sounds reasonable.  Do you have plans to co-maintain debrix and xlibs
with anyone?

[1] http://www.forbes.com/feeds/ap/2004/06/25/ap1434368.html

G. Branden Robinson                |
Debian GNU/Linux                   |      Ignorantia judicis est calamitas
branden@debian.org                 |      innocentis.
http://people.debian.org/~branden/ |

Attachment: signature.asc
Description: Digital signature

Reply to: