[xkb] Re: xkeyboard-config and modular release

[Alan Coopersmith]

Danilo Segan wrote:
>>Sergey Udaltsov wrote:
>>
>>>Tonight there was discussion on IRC regarding the integration process
>>>for xkeyboard-config. Talking about the porting to the monolythic
>>>tree, some points were mentioned:
>>>1. New dependency in the build process - intltool
>>
>>Which in turn brings in it's own dependencies, since last I checked,
>>intltool was incompatible with non-GNU versions of xgettext.
> 
> 
> Really? What do you have in mind?  intltool does support some features
> found only in GNU gettext (such as setting input encoding), but you
> don't have to use them.  If there are any other requirements, we'd be
> glad to work on fixing them, but we'd first need to learn about them.

Sorry - I thought our GNOME i18n team had reported them upstream after I
reported to them.  The use of GNU -- long options breaks it with Solaris
xgettext:

% intltool-update --gettext-package xscreensaver --pot
WARNING: This version of gettext does not support extracting non-ASCII
          strings. That means you should install a version of gettext
          that supports non-ASCII strings (such as GNU gettext >= 0.12),
          or have to let non-ASCII strings untranslated. (If there is any)
/usr/bin/xgettext: illegal option -- add-comments
/usr/bin/xgettext: illegal option -- directory=..
/usr/bin/xgettext: illegal option -- output=xscreensaver.pot
/usr/bin/xgettext: illegal option -- files-from=./POTFILES.in.temp
/usr/bin/xgettext: illegal option -- keyword=_
/usr/bin/xgettext: illegal option -- keyword=N_
/usr/bin/xgettext: illegal option -- keyword=U_
Usage:  xgettext [-a [-x exclude-file]] [-jns][-c comment-tag]
         [-d default-domain] [-m prefix] [-M suffix] [-p pathname] files ...
         xgettext -h

>>>3. Full compatibility with the current X.Org code (server, xkbcomp, setxkbmap)
>>
>>How many users will be broken?   Why is it a good idea to break
>>compatibility?   Why is it not a better idea to simply continue
>>to ship the working files we have and not break things for our users?
> 
> 
> Because those "working files" are unmaintained and contain a plethora
> of bugs?  If there's anyone who's willing to work to backport all the
> fixes from xkeyboard-config, that might seem viable, but unless not
> (and I suspect there isn't anyone), users probably want better
> layouts.

Fixing bugs is good.   Breaking existing user configs is not.   I'm not
going to ship config file changes that do that, and result in wasting
time and annoyance for our users, our tech support people, and myself,
without a really good reason.   I've wasted enough time digging out from
under all the GNOME "Internal X server XKB error" crap to go down that
rathole again voluntarily.

> However, all the sufficiently modern tools read xorg.lst or xorg.xml
> to get list of available layouts (or xfree86.lst/xfree86.xml), and
> these are even better with xkeyboard-config (they are translated, more
> complete, etc.).

Any tool outside the X server and it's bundled configuration tools that
reads XKB configuration files is broken by design, so that's hardly much
of an argument.

-- 
	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering