Uhm, did you read the part that says:Quote:
Originally Posted by 89c51
"We will not polish that, or add new features to that or anything."
You actually even quoted it.
Printable View
Uhm, did you read the part that says:Quote:
Originally Posted by 89c51
"We will not polish that, or add new features to that or anything."
You actually even quoted it.
I don't read this as we will not accept patches that let it built by itself. If someone posted a patch like that and lennart or kay rejected it -i am not following systemd that much- then ok.Quote:
Originally Posted by RealNC
I like how you fail to understand your own quote.Quote:
Originally Posted by 89c51
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?
I see the problem with assumptions possibilities ifs and whens. So in your case until the kernel introduces features that require a fork i don't see the need for one. But of course they are free to do whatever they want and fork whatever. In the same way people are free to built shelters because the end of the world (or the E17 release :p) is coming on the 21st.Quote:
Originally Posted by Xake
More drama.
https://plus.google.com/115547683951...ts/jcCjMct3SJ3
the moment when L.P. posted an email that udev outside of systemd is not supported anymore and there will be zero new features for udev-outside-systemd users.Quote:
Originally Posted by Teho
compare this:
http://comments.gmane.org/gmane.linu...ug.devel/17392
with this:
http://comments.gmane.org/gmane.linu....general/44475
William Hubbs wrote patches for that which Lennart Poettering rejected.Quote:
Originally Posted by 89c51
You mean these?Quote:
Originally Posted by ryao
http://www.mail-archive.com/systemd-.../msg05287.html
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.
That summarizes it.Quote:
Originally Posted by tuke81
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:
http://lists.freedesktop.org/archive...er/007763.htmlQuote:
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.
To complete the version:Quote:
Originally Posted by ryao
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.