Merged proto package

[Luc Verhaegen]

On Fri, Apr 09, 2010 at 11:43:52AM +0200, Florian Mickler wrote:
> On Fri, 9 Apr 2010 09:45:01 +0200
> Luc Verhaegen <libv at skynet.be> wrote:
> 
> > 
> > But don't the protocol headers each have packages depending on them 
> > separately, so that an update of the amalgamut triggers an update of 
> > many of the packages above the protocol header amalgamut?
> 
> is this a valid concern? 

Definitely.

> what libraries and packages depend on the new xproto package and how
> backwards-incompatible are the changes done to these proto's normally?
> 
> what other packages depend on these which do not depend on the xserver?

X is a client server architecture, and the proto headers define the 
protocol that exists between the clients (through libraries usually) and 
the xserver. Both the xserver and the clients depend on these protocol 
headers, but not all of those clients depend on the full range of x 
protocol extensions, especially not on the few very actively moving 
parts of those protocol extensions. Actually, what you will see is that 
none of the clients require the full range of proto headers.

When you mash all protocol headers together, you suddenly make all 
clients depend on all proto headers. I do not see why it is so hard to 
understand that this is A Horrible Thing, and why the same reasons have 
to be brought up over and over again. It is just very very obvious.

Take the dri2proto package, a quick google reveals that dependencies 
are: xserver, mesa, libvdpau, xf86-video-intel

A bump of dri2proto means a rebuild of just those 4 packages, and not of 
the lot.

> the thing is, that i get the feeling, that some of the driver writers
> don't want to have this n:m relationship between xserver and
> video-driver because they make fundamental changes to both(?) codebases
> which require parallel codepaths for different versions and thus split
> the testing coverage... they want xserver and driver to be 1:1.

This is not just a feeling. "some" of the driver writers do not want to 
deal with backwards compatibility and some of the overhead that it does 
create. They do not want to acknowledge that this actually a real need, 
and that it does have benefits too.

> but this is about the proposed merge of the proto packages.. let's not
> get carried away.

Oh, but the merging of the proto packages is solely about not wanting to 
bother with any form of backwards compatibility.

> cheers,
> Flo
> 
> p.s.: starting off in a thread with personal insults is probably not
> the best strategy if you want to be taken for full...

You mean the bit where i said that keithp doesn't want to care about 
backwards compatibility and hasn't bothered for as long as he has been 
doing driver development? This is just a plain fact, i would not put it 
beyond him to actually boast about this loudly and openly.

Luc Verhaegen.