Re: Missing file in libxklavier CVS

Well, may I state my vision of the problem.

I would highly recommend to people NOT to use libxklavier CVS but
instead use libxklavier tarballs. We could even put them to or whatever. I really would like NOT to put xfree86.xml
into libxklaveier CVS. Actually, the fate of this file is really

It lives as a module xfree86_xkb_xml in
It lives there since XFree 4.2.0 and ... well, I do not remember the
versions of libxklavier/gswitchit. This file is the directory of XFree
configuration repository. It is build using intltool so it potentially
can have any concievable translations of the existing models/layouts/...
It is the correct database (there is another historical database,
/usr/X11R6/lib/X11/xkb/rules/xfree86.lst - here I don't explain what are
the problems with it - just believe me it is incorrect and cannot be
fixed without breaking compatibility). Technically it was/is stupid to
have XKB configuration repository in one place (XFree86) - and the
information about it - in another (xfree86_xkb_xml). So during XFree86
4.3 development cycle this file xfree86.xml (resulting XML - not the
whole module!) went to XFree86 CVS. And unfortunately we have to keep it
that way - it would add dependancy (intltool) to XFree86 which we (Ivan
Pascal and me) do not dare to offer. So the technology kinda suck here.
People contribute new layouts to XFree86, modify xfree86.xml - then we
analyze commits, modify master (in xfree86_xkb_xml),
rebuild xml - and recommit to XFree86 CVS. And we are very "lucky" that
translators are not really working on this file yet (actually, there are
only 3 translations for a moment - Russian, Ukranian, Bulgarian). Shit,
isn't it? But we really do not know how do deal with it. We are really
not in a position to start the company for promoting intltool into

So, now, when you see the origins of this evil (well, technically very
helpful and necessary) file, I will tell you why it is in libxklavier.
Jody and me agreed that this file is going to be shipped with
libxklavier - so unhappy users of X servers other than XFree 4.3+ at
least will have "something" (which most probably only intersects with
the real configuration repository of X server). This file in libxklavier
is only a fall-back solution. And I really do not want to put it into
CVS - this will add me the headache of synchronizing this CVS with
xfree86_xkb_xml and XFree86 CVS. Now, when I maintain libxklavier and
make all the releases, I am sure that the file I use for libxklavier is
the latest version of xfree86.xml (actually, for a moment, the version
in XFree86 CVS is broken - it is actually wrong XML, not parsable:)

For the people who INSIST on building everything from CVS I would say -
OK - grab the CVS of xfree86_xkb_xml, build xfree86.xml, copy it over to
libxklavier - and here you are.

This is the way I see things. And I would prefer to keep them that way
(well, unless there is a violation of some policy on
hosted libraries - or gnome policy on external dependancies). Is it a
rule that any GNOME _external_ dependancy should be buildable from its
CVS? If so - I immediately apologise and add the file into CVS. If not -
I do nothing about it, I just have to ensure that libxklavier
tarballs/rpms contain that file (if not - kill me with all your

I hope folks you understand me. Having 2 copies of some file is a
problem. Having 3 copies of it - propagating the problem...



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]