[systemd-devel] PATCH: add support for compose_table, kbd_rate and disabling caplocks

[Kay Sievers]

On Fri, Aug 19, 2011 at 17:22, Frederic Crozat <fcrozat at suse.com> wrote:
> even if I know it is kind of SUSE specific, I was wondering if you were
> interested in merging attached patch (I tried to wrapped most of it
> inside TARGET_SUSE) which support more options from SUSE kbd
> initscripts.
>
> I haven't done yet another option which sets leds for numlock and so on,
> because I'm not sure I want it in vconsole-setup (reading bios data
> which should probably be restored by kernel itself, etc..) but probably
> in a separate helper (either C or shell).

This vconsole stuff feels a bit weird, not sure if there is something
that systemd should offer natively, but that's the first question to
answer.

Regarding ifdef TARGET_DISTRO: This is intended mostly to be able to
properly bootup, to make the distro's transition to systemd easier.
But the focus is *transition* here, TARGET_DISTRO should *map* old
config to systemd native config, but it should usually not, *add*
distro-only features.

I think, it should probably just go into some add-on package that also
allows per VT font setting and all that stuff some distros might want
offer here. I think, people who need such features should better just
install a kbd-exotic.rpm, like aaa_base-extras is. :)

All these TARGET_DISTRO and the support for the old file formats will
be removed from the upstream sources when things have settled. It
might take a while but it will happen. With hotplug it took us 3+
years or so, to do the same thing.

The longer-term plan is to have only one unconditional set of features
for everybody, and move the exotic things to specialized packages
which are not installed by default, and to put the burden of
maintaining non-upstream-able features to the distro's systemd
package.

What's the plan long term with that code we add here? TARGET_SUSE (and
all the others) will need to move to the distro's package after a
while, instead of having it available in the upstream tree. We need to
find a balance between making things easier now, and not to need to
throw out a lot of things when we are going to remove all the
TARGET_DISTRO stuff, which will happen after a while. Any ideas?

Thanks,
Kay