Merged proto package

[Florian Mickler]

On Tue, 13 Apr 2010 16:47:27 +0200
Luc Verhaegen <libv at skynet.be> wrote:

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

> > is this a valid concern? 
> 
> Definitely.
> 

I'm not so sure. See below.

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

These protocols are an interface-abstraction. They make it
possible to have different implementations for the same service. 

The protocols break the n:m dependency hell between xserver and
clients. By agreeing on a protocol, the xserver and the clients have to
be only compliant with the protocol and not every version of the
xserver with every version of those clients and vice versa.

The merging of the protos is orthogonal to that. If the protos are
stable, there is no reason to just make one big proto package?

I mean, of course, if you expect the protos to change heavily, then you
would have not a n:1 but again a n:m. And by merging the protos, you
increase the chance of the merged-protos-package changing. 

but if you keep the proto-version seperate from the
merged-proto-package version, nothing changes from the implementation
point of view. it only affects  packaging and distribution. 

and i guess few developers are using distribution packaging for
development? 

i mean here on gentoo i can install from git via emerge,
but that bypasses the gentoo-package-versioning.

let's step through it: 
so i emerge say the xserver live-ebuild and it fails because
package-x is too low in version. I then emerge that package. let's say
it is the new merged-proto-package.

now the installed proto state on my hard disk is the same as in a
non-proto-merged world, because the protos are seperately versioned
from the package.

So. And now? i have to somehow find the n packages that depended on
that to rebuild them. 

if there is no other way to find these dependencies than to rely on the
package-dependencies, i would say indeed. this proposed change does not
help me at all.

So i guess, one could say that you have a point there. Thanks for
bearing with me. I'm a little low on sleep today.


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

yeah. i see what you mean.  it really depends how fast moving the
packages are and what distribution you use and how you can calculate
the dependencies. 

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

and here i think you have a thinko, if the package-versioning is
seperate from the proto-versioning no code has to be written besides to
cater for the changed proto. 

cheers,
Flo