On Tue, 13 Apr 2010 16:47:27 +0200 Luc Verhaegen <[email protected]> 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 <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
