| |||||||||||||
systemd 183 releasedsystemd 183 releasedPosted Jun 1, 2012 13:40 UTC (Fri) by nix (subscriber, #2304)Parent article: systemd 183 released
* udev: /lib/udev/devices/ are not read anymore; systemd-tmpfiles
should be used to create dead device nodes as workarounds for broken
subsystems.
* udev: RUN+="socket:..." and udev_monitor_new_from_socket() is
no longer supported. udev_monitor_new_from_netlink() needs to be
used to subscribe to events.
And the merciless removal of features which people, and current software, are using, and which were recommended only a few versions ago, continues. This has been happening to udev for some considerable time, and is deeply annoying and potentially-boot-breaking every time it happens. Kay appears to have no grasp of the concept of backward compatibility at all. (Yeah, you can adapt to each change as it happens, which then makes it impossible to *downgrade*. Great.)
(For my own part I'm sticking with udev 175 until it breaks completely, which given the typical lackadaisical approach to backward compatibility in this area might be a few kernel versions away: devtmpfs just fills me with a sense of deep wrongness and layering violations and I don't want to rely on it.)
(Log in to post comments)
systemd 183 released Posted Jun 1, 2012 15:43 UTC (Fri) by ballombe (subscriber, #9523) [Link]
The udev-kernel interdependency is already the major problem when upgrading from a Debian release to another. This makes upgrade much harder than they need to.
systemd 183 released Posted Jun 9, 2012 21:58 UTC (Sat) by nlucas (subscriber, #33793) [Link]
This is really annoying.
I use /lib/udev/devices to automatically create the /dev/xconsole file on Ubuntu. After the change to upstart that file is no longer created, breaking xconsole.
If I don't have systemd, how can I use systemd-tmpfiles to create this file? Ubuntu will probably "invent" some way of doing this, while others systems will probably "invent" a second way. How is this contributing for the Linux ecosystem?
I also have a minimal udev system without any special init (a script file for sysinit and a second for shutdown). How will future udev work on this system? I'm also delaying using any new udev version while I can.
This situation of making udev "hostage" of systemd should never have been allowed...
systemd 183 released Posted Jun 10, 2012 0:37 UTC (Sun) by cortana (subscriber, #24596) [Link]
You can run systemd-tmpfiles(8) at some point during bootup and it will do the job.
systemd 183 released Posted Jun 10, 2012 1:46 UTC (Sun) by nlucas (subscriber, #33793) [Link]
Care to explain how to do it if Ubuntu doesn't have systemd?
systemd 183 released Posted Jun 10, 2012 13:12 UTC (Sun) by cortana (subscriber, #24596) [Link]
I expect ubuntu will drop their udev source package in favour of a systemd source package that produces a udev binary package, and a systemd-utils binary package including the misc utilities that others may find useful such as systemd-tmpfiles. Alternatively they could patch their udev code to re-instate the feature--it's hardly a particularly complex one. Or they could re-implement it, or adopt Debian's create_static_nodes script. Or adopt Debian's approach of having the rsyslog package create the FIFO (it's a simple change to the init script for the syslog daemon).
systemd 183 released Posted Jun 10, 2012 18:31 UTC (Sun) by nlucas (subscriber, #33793) [Link]
Why should you expect they include systemd-utils? I'm sure many of those utilities only work with systemd, so why should they package a mostly-broken package?
And if they adopt the current debian way (which by the way could now be considered obsolete because udev already changed how things should be done), then you have different ways of doing things on different distros. So what are the wins of using a new udev?
Anyway, I'm not talking of Ubuntu per si to do this. I'm asking of a way for users to do this in a compatible way.
What assurance can anyone have of any way they choose udev will not change it's mind again, now expecting people to have this things on a xml file on /etc/udev/extra-devices.xml and automatically removing any device not listed there?
I'm not a big fan of the kernel internal unstable API, but I can understand it's good points and accept it as a choice made by them. This, on the other hand, is just gratuitous incompatible changes into the user-space API without any good points I can see (other than breaking because it's "prettier" this way).
This is hardly the way into unifying the plumbing on Linux systems...
systemd 183 released Posted Jun 10, 2012 18:58 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
"I'm sure many of those utilities only work with systemd, so why should they package a mostly-broken package?"
This is a invalid assumption.
systemd 183 released Posted Jun 11, 2012 14:08 UTC (Mon) by nlucas (subscriber, #33793) [Link]
That surprises me a lot.
Why call it systemd-utils then? Shouldn't it be just udev-utils? And be part of udev only?
Doesn't make much sense. What user will guess that it needs to install a package with a name of other that doesn't exist on his system to get utilities for a second package?
systemd 183 released Posted Jun 11, 2012 14:18 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
You are confused. There is no separate upstream release called system-utils. OP's suggestion was to package a bunch of the independent tools under a distribution package by that name. systemd-tmpfiles for instance is only called by that name since it was written as part of the systemd project. It doesn't depend on systemd being the init system. Even if reimplementation is needed by distributions who haven't used systemd, documentation on the interfaces already exist and independent reimplementations have been written by various distributions as well.
http://www.freedesktop.org/wiki/Software/systemd/Interfac...
systemd 183 released Posted Jun 11, 2012 17:15 UTC (Mon) by nlucas (subscriber, #33793) [Link]
You are right. I was confused. Thanks for the link so I could clear this up.
Either way, a user-space udev API was broken. The solution pointed was to use a systemd API to solve the problem.
It's still a compatibility breakage, and if that solution is to be used across distributions it should be discussed outside systemd, not forced on all distributions. udev is a crucial Linux plumbing infrastructure. systemd isn't (at least not yet) so it can not force global policy and compatibility APIs.
The same applies for DBUS. It can eventually be considered an essential package on desktop Linux, but it's far from it on a global scale. So udev can make a DBUS API available, but never have an hard dependency on DBUS (or any DBUS utilities or API).
For example, there may be reasons for having udev on an Android system, but there are no strong reasons to have DBUS or systemd. The same for other specific-use or embedded Linux systems.
systemd 183 released Posted Jun 11, 2012 17:38 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
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.
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.)
systemd 183 released Posted Jun 11, 2012 22:07 UTC (Mon) by nix (subscriber, #2304) [Link] Either way, a user-space udev API was broken.This seems to happen every month or so. It's not like this is the first or even the tenth time. Most of the changes add no value that I can see. I'm frankly sick of it, so I'm sticking with udev 175 until it breaks, and then backporting appropriate kernel changes to keep it working, or forking it with the intent of maximum compatibility with existing installations, whichever is easier.
systemd 183 released Posted Jun 11, 2012 22:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Uhm.
Udev is a very low-level component. Why are you maintaining your own config instead of using distro-provided one (maybe with small customizations)?
systemd 183 released Posted Jun 12, 2012 7:33 UTC (Tue) by nix (subscriber, #2304) [Link]
Because I am a UI stability freak. I have extreme distaste for people breaking my working environment, so every physical system I own is currently LFS simply so that user-facing components on whose UI I rely can avoid being jumped to versions that change the user interface in major ways. Not udev, as such (that's just very annoying: I have to run it but I don't like to be bothered by it), but things like the desktop environment, for instance. Now maybe I should just be using xfce, but it so happens I'm a KDE 3.x + fvwm user. These days, some people package Trinity, but there was a long time when I was using KDE 3.5.10 and no vaguely up-to-date distro packaged it: there are other major components that I am intentionally far behind the curve on too. At the same time I want or need to use bleeding-edge trunk versions of some things (kernels, toolchains, QEMU, Emacs, Chromium), a lot of which have substantial local patches applied.
There are few distros optimized for stick-in-the-muds who also need to use and patch bleeding edge low-level software, and I can understand that. Nobody else is likely to want to use the same combinations of bleeding-edge stuff as I am, and handling all the possible combinations is a combinatorial explosion. Most people in this position use a distro, locally compile lots of stuff, and try to cope with the much-too-frequent disruptive UI changes. I'm not willing to do that. Sometimes this means I whine about people who assume that everyone uses a distro that someone else maintains (and that downgrades never happen) and that they can break low-level components' compatibility frequently without anyone at all caring. People like me do still exist. We may be a small constituency of control-freakish eccentrics but we are not nonexistent. :)
(As a side note, the reasonably high degree of low-level knowledge that doing this sort of thing requires *did* actually get me a pretty damn good job. So it wasn't a complete waste of time after all!)
|
|||||||||||||