| |||||||||||||
systemd 183 releasedsystemd 183 releasedPosted Jun 11, 2012 17:38 UTC (Mon) by rahulsundaram (subscriber, #21946)In reply to: systemd 183 released by nlucas Parent article: systemd 183 released
The primary developer of udev is one of the co-maintainers of systemd upstream and hence they are working together on some changes. This isn't forced on anybody anymore than any other upstream choices in development is. Distributions are free to patch it back or reimplement interfaces as they already have and systemd developers go out of their way to document these interfaces and provide a stability promise to make all of this easier.
It is arguable that systemd isn't crucial infrastructure yet but I dont consider it valid to argue that dbus isn't for desktop linux. All major desktop environments and several critical desktop applications depend on it. Note that systemd depends on the dbus protocol and not the daemon. Android certainly doesn't count as evidence for that considering that it is a entirely separate ecosystem that shares pretty much nothing other than the kernel.
(Log in to post comments)
systemd 183 released Posted Jun 11, 2012 17:57 UTC (Mon) by sfeam (subscriber, #2841) [Link] To the best of my knowledge Xfce does not require dbus.
systemd 183 released Posted Jun 11, 2012 18:10 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Update your knowledge.
systemd 183 released Posted Jun 11, 2012 18:45 UTC (Mon) by sfeam (subscriber, #2841) [Link] According to the release notes for Xfce 4.10-pre1, dbus is a "soft requirement" for some of the new functionality. I took them at their word, but I admit to not having tried building without it. In earlier versions it was only listed as being required for thunar.
systemd 183 released Posted Jun 11, 2012 18:52 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
The thing about "soft requirements" is that unless you are using a source based distros, it is highly likely your distro of choice will pull it in when you install Xfce. dbus is effectively a requirement for Linux desktop.
systemd 183 released Posted Jun 11, 2012 18:35 UTC (Mon) by nlucas (subscriber, #33793) [Link]
It seems to me we give different weights to different things. For me, any user space API breakage is wrong without *very strong* reasons. And it's worst if that breakage is in a crucial package like udev.
I did say that dbus is an important desktop package, so we don't disagree there (we could disagree on if it should be or is desirable that it is, but that's irrelevant). I don't think it's an essential package, but it's certainly desirable for everything to work as expected from the user point of view. It certainly is possible to use a Linux system, even with X, without it.
My point was that dbus is not an essential package on every system (servers, for example, if you believe Android and the other billions of custom systems are irrelevant), so udev should never depend on it, in the same way that udev should never depend on systemd, because it's another non-essential package.
Note that I'm not saying udev should remove all DBUS interfaces it already implements. I'm just saying it should be possible to use it without dbus.
There is nothing strange here. The same can be said on any other non-essential package, like having udev depend on python, or java. But nothing forbids udev for having python or java interfaces on the systems where they are available.
systemd 183 released Posted Jun 11, 2012 18:48 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
It is possible to continue using udev without systemd or dbus so I am not sure what your point is, really. Having said that, dbus isn't limited to desktop systems anymore since cups and even bind can take advantage of it.
systemd 183 released Posted Jun 11, 2012 21:20 UTC (Mon) by nlucas (subscriber, #33793) [Link]
My point is the same as the original poster on this thread: gratuitous incompatible changes on a core package is BAD.
I don't agree with you on dbus, but that's irrelevant (just because dbus can be used on a server doesn't mean it's required or essential).
systemd 183 released Posted Jun 12, 2012 10:31 UTC (Tue) by cortana (subscriber, #24596) [Link]
The breakage is annoying but we could, at least in theory, end up in a situation where all distributions use the same /etc/tmpfiles.d configuration method. IMO that is worth a bit of pain. Particularly when the new method is better documented than the old one: I don't ever remember hearing about /lib/udev/devices until this discussion: for whatever reason Debian doesn't even use it, it has its own /etc/udev/links.conf file that explicitly says in its header that "This file does not exist. Please do not ask the Debian maintainer about it.", etc.
OTOH we could end up in the situation evoked by http://xkcd.com/927/. Maybe it's naive to be so optimistic, but a world where everything in http://www.freedesktop.org/wiki/Software/systemd/Interfac... is adopted by all distributions would be quite pleasant: a world where you could configure all this low-level stuff on any distribution without having to deal with all the pointless differences between them.
http://0pointer.de/blog/projects/the-new-configuration-fi... has more info about the rationale for all of this. Admittedly it's a long shot for the distributions that aren't adopting systemd as their primary init system.
systemd 183 released Posted Jun 12, 2012 11:00 UTC (Tue) by nlucas (subscriber, #33793) [Link]
Debian is (at least in theory) kernel agnostic, so it can't depend on udev, which is Linux specific.
You may never heard of /lib/udev/devices but that just means you never needed it. It was added when /dev started being a tmpfs filesystem (and now devtmpfs), because devices were no longer preserved across reboots.
At the time was not an API break, because people could still use a static /dev, and so was backward compatible. In the meantime other breakages occurred.
Anyway, the problem here is not this specific feature: it's the fact that udev AGAIN broke an API. The problem is not systemd or any other software, it's the fact people working on the core Linux plumbing are constantly annoying it's users.
This would not be a problem if we had some user-space wrapper abstracting this lower level stuff. But we do not, so please don't regard low level APIs as things that can change any time just because they can. They are as much standard APIs as brk(), sbrk() or malloc(), and there are people using it.
systemd 183 released Posted Jun 12, 2012 12:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Udev is arguably special in that regard. It's in constant flux because of new hardware or new ways to configure it.
Udev's primary API is /dev filesystem structure - which is stable, btw.
systemd 183 released Posted Jun 12, 2012 13:06 UTC (Tue) by nlucas (subscriber, #33793) [Link]
The kernel is in the same state of flux and that doesn't mean the user-space API is broken.
/dev is only one of the udev API's. libudev is another, as are the DBUS bindings.
None of them should be considered second order APIs. If they exist they will be used by someone somewhere. If they break, someone will be annoyed. If they are constantly breaking more "someones" will be annoyed.
One thing that seems not everyone grasps is that Linux has probably more usage in customized systems than on desktops. udev was published as the rescue for this low-level plumbing, even on customized systems, because USB happened (needed to load modules on demand, creating/removing devices, etc). This systems could use other things (like mdev), but udev is the only one generic enough for most usages (mdev doesn't cover all modular cases).
Android decided to not use udev, but it will need to reinvent it (if it doesn't start using it) for the generic tablet cases (when tablets, maybe docked, replace laptops).
systemd 183 released Posted Jun 12, 2012 13:09 UTC (Tue) by nlucas (subscriber, #33793) [Link]
By the way, I don't mind a little API break once in a while. It's good to cleanup accumulated cruft.
The problem is the constant breakage, not one or other "flag day".
systemd 183 released Posted Jun 13, 2012 16:24 UTC (Wed) by nix (subscriber, #2304) [Link]
Quite. They even moved the daemon around between releases and didn't even have the courtesy to maintain a compatibility symlink (total cost: one line of code in Makefile.am's install rules). I can see no advantage to moving the daemon out of the directory where all other system daemons are located -- it was just done for the hell of it, as far as I can see, but of course it meant everyone had to adjust their boot scripts, and either load them up with compatibility crap in case of downgrades or lose the possibility of downgrading without breaking boot.
(However, they *are* very good at telling you what the compatibility breaks will be, so you *can* adapt to them. But every upgrade feels like skydiving with a possibly-broken parachute, and it shouldn't.)
|
|||||||||||||