"We will not polish that, or add new features to that or anything."
You actually even quoted it.
Say that newer kernel introduces the possibility of some new features when it comes to how modules/firmwares are handled, and you want your system to make use of them.
Then according to that letter you quoted you either have to start using systemd-udev (that is systemd and their version of udev), or fork udev.
This since the standalone-version of udev you can build from the systemd sources will, according to your quote, not receive polishing nor new features.
See the problem with that?
So if I understand this right in systemd-devs pov if you wanted to use only udev you have to compile whole systemd at the same time. This would be ok binary distros like ubuntu and tho upstart, but not in source distros like gentoo. If I would want to use only udev with gentoo I don't want to compile something that are not needed, it's just a waste of time and resources of my own computer. And what Hubbs suggested with his patches is to add two configure flags that make possible to compile only udev.
For what it is worth, Koen tried yesterday to upstream a patch that I wrote to restore support for older kernels, but it was rejected. Kay Sievers wrote a longer email than what I quote here, but here is an abridged version:
We generally do not want to work around kernel or libc "bugs". So I'm
not interested in such a patch.
People who want or need to play these match-and-mix games with "new
userspace on old systems" should fix the dependencies where they are
missing, not expect "magic" workarounds from tools. There are many
subtle dependencies on various things which are not available on old
kernels and libc, this is just a very obvious one. We should not
pretend we support that model, we just don't. And it will get even
harder in the future, as we are trying to build a real OS now not a
"bag of bits".
The two projects have orthogonal priorities. eudev favors long term compatibility as a modular component while systemd favors the single tree approach where support for older versions of components is pointless. Both have merits.
Is that what eudev was all about? Running newer udev on very old kernel release?Quote:
We surely will not make anything harder than it needs to be, but
pretending bleeding edge tools will or should work on 2 years old
kernels is a promise we do not want to make with systemd/udev. In this
case, it would be the job of the libc, not the user of libc.
We surely support things the other way around, what the kernel is
doing, which is new kernels on old systems, but doing it both ways is
not really the goal for us.