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

Re: Future of X packages in Debian

On Tue, Jun 29, 2004 at 12:11:29PM -0500, Branden Robinson wrote:
> 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
> marketplace[1].
> My condolences.

I saw that on Slashdot and laughed bitterly. But at least it's time for
us to deploy it to a wider audience before they release it again. :)

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

For sure - we have a policy for our X stuff that includes not importing
and running away; if you put your name to something, you're responsible
for it.

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

Let's cross that bridge when we come to it, I suppose; it would be more
fruitful to have that discussion when I have working packages.

That said, yes.

Daniel Stone                                                <daniels@debian.org>
Debian: the universal operating system                     http://www.debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: