Is this the discussion? http://www.mail-archive.com/systemd-.../msg05287.html
Originally Posted by tomegun
I see it boiled down to: "here's a patch to allow me to build udev as I've always done for years". Some of the answers?
- no, sorry.
- you have to split it in your distro.
- stay with udev-182, it's the easiest way! [sic!]
- do it yourself for now, eventually your patches will be accepted but not now, [7 months have passed at the time of this writing] and anyway you'd be better off by switching to systemd
I've just installed udev from systemd-197. Thanks for at least having made Python optional on the target, this helps when bootstrapping a cross-compiled image. However, now libudev links with libsystemd-daemon, so the integration between systemd and udev apparently went a step further and now there's another piece of systemd I need to have on my system only to run udev. Ressured by you, I shut up and install the library, knowing that it won't harm me.
If you switch off 'everything' in ./configure, you will basically just have to compile systemd, journald and udevd. From a point of view of compile-time this is not a big issue, the only possible issue is if you for some reason absolutely don't want libdbus as a build-dep. In that case I suggest you look at the Makefile by LFS, they do this nicely.
Since you're pointing at LFS, in all honesty, can you find on the whole LFS site another package whose installation requires such a complex and elaborate procedure every time a new release is out? One! Bonus points if it's a system package which is needed by any application to interface itself with the Linux kernel.
I hope so. I have to live in hope (so much for "nothing will change"). The biggest problem is that he should gather quite a critical mass of users in order for his implementation be tested well-enough to be a viable replacement, but well, that's true for many kinds of project. Also he'll need quite a dose of endurance to harsh criticism. Let's see what happens with eudev.
Nah, if that were to happen I'm sure someone who knows what they are doing would step up and make a proper and maintainable fork.
Why are you putting on the same plane the case of udev with that of "any other subset of binaries"? The case of udev is unique and the reasons for needing only it have been documented -- countless times in this thread only.
A patch to JUST build udev is simple. However, for it to make any sense upstream you should not make it a special-case, but allow to also build any other subset of the binaries, which becomes a mess (apparently, I didn't look closely at the patch, except to count the number of lines).
It makes sense for udev users to build only udev. You say that it does not make sense upstream, so apparently there's some thing that you call "upstream" whose interests are in conflict with a portion of the downstream udev users, namely all those who use udev but not systemd. Which is what I've been ranting about all the time, with people telling me that it was not true.
In your previous message you told me repeatedly that I could use Linux without udev, now at least you're saying that "most clients no longer care about the non-udev usecase". So I can use Linux without udev, I'll just have to do without "most clients". Lucky me :D .
I see systemd's trajectory something along the lines of udev's: it started out as something people 'would never allow on their systems', before it slowly became a de-facto standard to the point that most clients (e.g. X, or various init systems) now no longer care about the non-udev usecase.