and the Makefile contained in this tarball.
It would be much more convenient if it supported a --only-udev build, but my understanding from the LFS developers was that a) upstream weren't interested, and b) this standalone Makefile was actually easier than patching the systemd build files. Certainly, udev is one of those packages that doesn't benefit much from using an autotools build, since it's not intended to be portable, nor does it have a set of complex dependencies to check for.
Most importantly at all, those design principles are something you're supposed to think about, not just follow automatically without appreciation of what you're gaining (and losing) by doing so.
Or, if you run Linux on an embedded board that is controlled through a serial port, you can be fine with mdev.
But in reality, if what you use is the plain desktop Linux, then you need udev and libudev even for basic tasks such as starting the X server.
It gets updated when drivers get merged into / updated / removed from the kernel and this reflects into udev rules. Also libudev changes frequently and userspace needs the new APIs.It is not true that "udev is constantly changing together with the kernel".
Great news! Then certainly before long all those non-systemd developers that contribute to systemd-udev, and decide and shape its future, will give us a Makefile target for us to build and install udev separately from systemd. I'm looking forward to that moment, I hope it won't take long!The concern is understandable. However, you should by now have been told repeatedly that 1) non-systemd support for udev will continue as long as non-systemd uses exist (and they do, Martin Pitt of Canonical/Ubuntu fame has commit access to systemd-ubev for crying out load)
And yet currently it's the only alternative I'd have should udev be integrated into systemd when everybody "sees the light" (besides switching to Android or BusyBox as you've suggested above). So I hope they'll fix the problems they have; I'm certain that systemd-udev developers will help them and encourage them, in the spirit of open source collaboration.if ever udev becomes dependent on systemd creating a fork would be trivial (don't look to eudev as an example, what they are doing is crazy and creating a lot more trouble/bugs/work for themselves than necessary).
I never said that it does not work without systemd. I said that it does not build without systemd, which is a rather big change, while they said there would be no change, and that it changed the way it works in a way that broke my system, for example by changing the name and position of the main udev binary.That's news to me. Udev works just fine without systemd. We supported that for some time in Arch Linux without problems and we still support udev without systemd in our initramfs.
Are there such switches? The last version I've built, 191, didn't have them, so I had to build the whole systemd and then guess what files I had to take out from it. I'm happy to know that now they're in place, I'll download and install 197 as soon as I have time.You do not have to build all of systemd to build udev. With the correct packaging script building only the necessary is trivial. That said, the simplest approach is probably to just flip the right ./configure switches to avoid building almost all of systemd.
Python was hardcoded in the makefiles the last time I built udev. I know because I was cross-compiling it, like I had always done when udev was a standalone package, and could no longer do it because of Python. Again, I'm happy to know that this changed, it will save me a lot of time.If by 'many' you mean 'two', then you are correct: libcap and dbus. python (and everything else) is an optional dependency, which you would obviously disable in your setting.
I'm no distribution maintainer. It takes me a lot more than 5 minutes to study, dissect and rebuild a package that is essential to boot and keep my system running, and repeat this operation every time a new systemd release is out. If such a patch would be "extremely trivial", then why a patch that does exactly this was never accepted upstream?It was just a matter of deleting some stuff and moving some stuff, I don't see what the fuss is about. If you prefer to have patch against the Makefile to make this even more trivial, that would be an obvious thing for your distro to carry if they don't wish to use systemd. The patch would be extremely trivial... Only reason I never wrote this (would take 5 minutes) is that my distro uses systemd so there is no point.
You're actually confirming my concerns. Especially with the last sentence, where you go as far as delineating a difference between light and dark.You are misreading this statement, and it has been explained repeatedly. They (we) are looking forward to the day when there is no longer a need for non-systemd udev. Meaning the day that everyone has seen the light and switched to systemd.
When I said that people are planning "to stop supporting udev without systemd in a somewhat unspecified future", you told me that it was "a gross misrepresentation, and absolutely not true". But to me "as soon as Ubuntu starts shipping systemd by default" is the same as "in a somewhat unspecified future", because I don't work at Ubuntu and have completely no idea about their future plans.As long as Debian/Ubuntu are not using systemd by default you have nothing to worry about.
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. Once systemd has reached this same status, I suppose it would become relevant to discuss whether or not udev should also drop the non-systemd usecase. I believe this has more to do with what the ecosystem userspace apps does (when they start hard-depending on systemd) and less to do with what default init-systems distros use.
Your moms are Monolithic (to BSD users/devs)Systemd Is Monolithic
Cause systemd is so well designed and simple unlike BSD init. Systemd is simple, small and fast so those guys saying under wise should grow up or get lost.Systemd Is About Speed
BullshitSystemd Is Complex
Good, BSDs hold back open-source projects. They always have to waste effort porting their software to pathetic BSDs. Much better forgetting about them and make software that takes advantage of superior Linux specific features. BSD users should just crawl into a hole and die cause their OS is 20 years behind and they do nothing but hold linux back.Systemd Is Linux-only & Not Nice To BSDs
That's irrelavent, systemd was made for linux and LINUX ONLY. If BSD don't like it, they can go screw themselves. Just ask GNOME, XFCE and KDE devs about how annoying the existence of BSD is. They'll tell you that BSD only makes up 0.01% of the users of their software and that they could make their DEs better without BSD to worry about.Systemd Is Not Portable For No Reason
So those criticizing systemd shown just STFU