The way udev deprecates keymap

This, this, this, and this epitomises what is wrong with development of systemd/udev in general.

The first post outlined the idea of a major change (and the reason for that), the second post informed that the code is now available, the third post said that the old code is now gone, and the last post said that documentation is needed.

Ok, what's wrong with all that?

1. The reason for change is wrong: keymap rules aren't really that long.

2. The duration between the initial new code commit and the removal of existing functionality is 4 days. We're talking about major change here, breaking previous udev rules that have been working for years.

3. By the time the old code was removed; the new code wasn't complete yet (the data files required for new code was still work in progress - "Martin is still working on it...").

4. In case somebody wanted to help, well ... let's wait until someone volunteered to write the documentation first, shall we? Of course, this was after removal of existing, working code.

I'm not against new functionality. New functionality, new way of thinking are always good (and even if they turn out not to be; they are still worthwhile as they show that the old way of doing thing is still better). What I'm against is major feature change that breaks configurations that have been working for years at the snap of the finger. What's wrong with backward compatibility? It isn't like hwdb and keymap can't be made to co-exist together.

Did they consider this?

5. The new hwdb keyboard mapping depends on DMI. How about platform that don't expose DMI? Didn't think of that, do we? Or perhaps they can screw themselves? Or is it "the kernel bug - ask the kernel team to surface DMI for those platforms"? Yeah, sure. We heard them before. Linux kernel deprecates many features over the years. Not a single one of them was deprecated in four (4) days without co-existence of some sort - especially one that breaks existing functionality in userspace.

Lastly, not so important but still annoying: There is a reason why keymap files are separated into many different files. It is called "ease of maintenance". The new hwdb format for keyboard mapping? Oh it just a giant keymap file, with all the information combined (indexed by DMI/USB ids). It is so much easier to edit a giant file and run "udevadm hwdb --update" than keeping the information in separate files, one for each keyboard type, isn't it? There is a reason why applications that handles large diversity uses separate files (e.g. terminfos, printer definition files) - could you imagine if the maintainer of these combine all those data into one giant file?

I'm not buying the idea, so here is the udev-keymap tarball from old udev, re-packaged to build as an independent package (no udev required). It will work with udev; it will co-exist with the new "keyboard handling" (provided the rules don't clash); it will work with your previous keymapping rules. My only contribution was the new Makefile to make it build. The rest come from here.

An another note - it is a sad day that Debian finally caved in and went with systemd. The problem with systemd is not only technical; it's also about the attitude - as this example illustrate.


Posted on 11 Feb 2014, 19:00 - Categories: Linux
Edit - Delete


No comments posted yet.

Add Comment

Title
Author
 
Content
Show Smilies
Security Code 0452715
Mascot of Fatdog64
Password (to protect your identity)