XKB configuration data and xkeyboard-config

[Kevin E Martin]

On Wed, Jun 22, 2005 at 08:54:22PM +1000, Daniel Stone wrote:
> On Tue, Jun 21, 2005 at 11:47:32PM +0100, Sergey Udaltsov wrote:
> > Just to remind you the matter of problem:
> > [...]
> > In order to be released as a part of non-modular 6.9 release,
> > xkeyboard-config should be imakefilezed back, Also, this step, if
> > performed would introduce new build-time dependency for Xorg -
> > intltool. And, as I said, the configuration compatibility between 6.8
> > and 6.9 will be broken. All these factors show that releasing
> > xkeyboard-config as a part of 6.9 is essentially waste of time.
> > On the other hand, something has to be done. A lot of bugs are
> > reported as "fixed" in xorg bugzilla - but people never actually see
> > fixes, because they are in xkeyboard-config which cannot be easily
> > (naturally, without patching) dropped into existing tree.
> > So, possible ways:
> > - forget about xkeyboard-config till 7.1. It is a safest way - but
> > very bad IMHO. Long-outstanding bugs in existing xkb repository - will
> > still be around for a year or more (adding the time it takes for Xorg
> > release to get into distributions)
> 
> Right.  On the other hand, it will ensure consistency.  But people
> probably won't expect configurations to break in a .1 release.

The issue is that 6.9/7.0 has the exact same code, and we need to
maintain that status for the initial release.  We plan to open up the
modular tree for new code after the 7.0 release.

> > - split existing xkb configuration data into separate module, without
> > any other changes/fixes. This is the minimal reasonable solution - at
> > least distromakers would be able to substitute it easily and naturally
> > with xkeyboard-config.
> 
> We can do it today, very easily.  Either you don't build the data files
> in programs/xkbcomp, or you just ignore them in your install target.

As a vendor, this solution would allow me to either distribute the
xkbcomp data files that comes with 7.0 or to substitute the ones that
Sergey has created.  So, I like this solution since it is both forward
looking and still maintains consistency between the 6.9/7.0 release.
See below for a variant of this solution that might work better.

> > - release 6.9 with old xkb configuration data, release 7.0 with
> > xkeyboard-config. It would be rather radical step - but it would
> > guarantee that people using 7.0 will have all the fixes, all the old
> > data would be dropped
> 
> I think this is probably the most sensible decision to take.  7.0 is a
> new major version, so it's probably our best chance to break
> configuration compatibility if we need to do so.

This is not an option since the combined 6.9/7.0 release is designed at
its heart to contain the same code.  Note that there will be other
changes after 7.0 -- I believe someone has already started a list and if
not, then we should start one in the wiki.


Another option would be to for you to create a complete replacement for
xkbcomp in your repository that includes both the xkbcomp program as
well as all of your new configuration data files.  I think this is
easiest solution to implement, since with modularization, picking and
choosing exactly which components are included in a vendor's release is
trivial to do.  So, for vendors that want the new configuration data
files, they would simply substitute the xkbcomp package that you provide
as a 100% replacement for the one provided in 7.0.

Kevin