xcalibrate

[Peter Hutterer]

On Tue, Aug 11, 2009 at 09:01:20AM +0200, Robert Schwebel wrote:
> In order to avoid further dumb questions on my side: is there an
> established release / versioning policy for x.org? Something like
> 
> - released versions are supposed to work/compile
> - released versions are supposed to compile if their explicit
>   dependencies (via pkg-config) are fulfilled
> - versions in rev. x.y are supposed to work with other versions with
>   whatever version scheme

there is a number of dependencies of various packages and no single answer.

for example, if a released package B depends on A you can't necessarily
update A without breaking the currently released B. without an update to A,
you can't always release the next B. packages can't always backwards
compatible with everything.
So at any point in time you may have released modules that only work with
non-released modules.

As such, there isn't really a single, definitive, answer. This is one reason
for the X11R7.X releases, they represent a snapshot of modules working
together.

In the X.Org infrastructure, the server tends to be the central piece, so
updating often goes backwards from the server. i.e. if you want to get
server X running you update the required dependencies and go from there.

> Some words about the background: I'm curretly updating the x.org support
> in ptxdist, which was previously based on the official 7.2 release. The
> reason is that we have more and more embedded systems with x86 CPUs,
> both in our commercial projects at Pengutronix and in the ptxdist
> community (all recipies are public - ptxdist is licensed under the GPL).
> 
> So following our "send-patches.org" strategy (if something doesn't work,
> try the latest-and-greatest from upstream and improve *that* instead of
> random hackery on old stuff), I've naively started to take all latest
> released versions of all packets from the server, updated the ptxdist
> recipies and tried to build that.
> 
> In contrast to the build.sh script, ptxdist has full configuration
> support. So we have almost all --enable/disable switches in Kconfig
> menues; in the end, we make embedded systems which need full
> configurability.
> 
> My experience so far is that, in contrast to the last try two years ago,
> x.org has massively turned to the better. However, there are still some
> things where we trap into dependency hell, sometimes even not
> resolvable. One example is that if I update xext (lib+proto) to the
> latest release, I cannot build xorg-server any more. Downgrading it
> results in several other versions which have to be downgraded as well.
> 
> So I'm wondering: is this a bug worth to be reported? Should I try some
> git head for xorg-server which works with the latest xext? I checked the
> xorg-server head, but it doesn't seem to be linear, so I'm wondering how
> close to the next release it would be if I tried that. Being more an
> integration person than an xorg developer, I don't want to build
> everything from the git heads (that's probably what the maintainers do),
> but only selected components.

In the case of xextproto this effect was known.
http://lists.freedesktop.org/archives/xorg-announce/2009-August/000953.html
this is one example of the A-B dependency mentioned above.

I do admit though that our release announce emails are somewhat short and
could need more information to help with exactly this kind of issue.

Cheers,
  Peter