Merged proto package

[Dan Nicholson]

On Thu, Apr 8, 2010 at 4:40 AM, Peter Hutterer <peter.hutterer at 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