On Thu, Apr 8, 2010 at 4:40 AM, Peter Hutterer <peter.hutte...@who-t.net> wrote: > On Thu, Apr 08, 2010 at 02:33:22AM -0500, Yaakov (Cygwin/X) wrote: >> On 2010-04-06 17:41, Keith Packard wrote: >> >I've written some scripts that construct a merged proto package from the >> >existing proto packages. They're not fancy, but do preserve the entire >> >history of each sub package as they get merged in. >> > >> >The goal is to make the installed files exactly match what the existing >> >packages install, so that no API or ABI changes would exist. This >> >includes installing per-extension .pc files with the current version >> >numbers. >> > >> >Please let me know whether this seems like a good plan, and if so, I'll >> >move it into the /git/xorg tree and we can work on deprecating the >> >individual protocol packages. >> > >> >Testing and comments welcome. >> >> Some comments from the POV of both a distributor and one who deals >> with a system-unique DDX: >> >> 1) Keeping per-extension proto .pc files makes sense wrt to >> compatibility, but perhaps keeping all the old version number >> schemes does not. For example, in the future, if a package requires >> compositeproto >= 0.4.2 (after some future update), how will anybody >> know which version of the all-in-one "proto" package provides that >> version of compositeproto? > > export them as separate variables in the pc file. That's probably better > than the current situation where the protocol version is sort-of tied to the > package version, which screws us both ways. you get to either break the wire > version for updating the packages or you push out an backwards-incompatible > packaging change with only a patchlevel bump.
But that still doesn't tell you anything about which proto-x.y.z version you need. Someone would need to have strong release announcements at the least to not drive people crazy. I'm also gonna go out on a limb and say that using the protocol versions as the version numbers in the .pc files will get you in trouble at some point. If that was the case, the inputproto.pc version would have been 2.0 for 11 releases from inputproto-1.9.99.8 to the current 2.0. In that case, it would become a lot more difficult to know that you had an incompatible set of headers that just claims to support the necessary protocol version. So, I think the individual proto packages still need to keep their own concept of a version independent of the protocol version, or they should all just sync to the top-level version number. People tend to not like that the versions in the .pc file are decoupled from their internal versions, but following the package version is the only sane way to handle it. You can always add another variable to export other concepts of version. -- Dan _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel