Weekly Edition
Return to the Distributions page
| |||||||||||||
Gentoo's udev fork
The ability to fork a project is one of the fundamental freedoms that come
with free software. If a software project is heading in a direction that
is less than ideal for its users or developers, a competing version can be
created and managed in a more useful manner. Forking has been used to
great effect with projects like Emacs, GCC, OpenOffice.org, and XFree86.
The most successful forks have specific goals in mind and tend to attract
at least a significant subset of the original project's developers. Other
types of forks face a harder road. Arguably, a recently launched fork of
the udev utility under the aegis of the Gentoo project is of the
latter variety.
On November 13, the Gentoo council met to discuss, among other things, how to support systems that are configured with the /usr directory on a separate partition. The meeting minutes show that much of the discussion centered around a new udev fork that, it was hoped, might help to solve this problem. The existence of a new udev fork (now called eudev) within the Gentoo project took some developers by surprise, especially when the associated README file was observed to claim that it was a "Gentoo sponsored" project. This surprise led Greg Kroah-Hartman (a longtime Gentoo developer) to ask what the goals of the fork were. Getting an answer to that question turned out to be harder that one might have expected. One of the developers behind eudev is Richard Yao; his response really needs to be read in its original form:
If we were using the waterfall model, I could outline some very
nice long term goals for you, but we are doing AGILE development,
so long term goals have not been well defined. Some short term
goals have been defined, but I imagine that you are already
familiar with them.
After extensive discussion with a lengthy digression on copyright law (the eudev developers removed some copyright notices in a way that drew objections), some of the project's motivations came into a bit of focus. Part of the problem is certainly the increased integration between udev and systemd. Udev is still easily built as a standalone binary, but some people worry that this situation might change in the future; mere association with systemd seems to be enough to provoke a response in some people. That response carries over to the ongoing unhappiness over the deprecation of /usr on a separate partition. The developers involved claim that this configuration has not been supported for years and cannot be counted on to work. In truth, though, it does work for a lot of people, and those people are feeling like they are having a useful option taken away from them. Whether a fork like eudev can address those concerns remains to be seen. Beyond that, a recent switch to the "kmod" library for the loading of kernel modules has created a certain amount of irritation; backing out that feature is one the first changes made by the eudev developers. Udev uses kmod for a reason: avoiding modprobe calls speeds the bootstrap process considerably. But Gentoo developers like fine control over their systems, and some of them want to use that control to exclude kmod, which they see as unnecessary bloat or even a potential security problem. If udev requires kmod, that desire is thwarted, so the change has to come out. There was also some discontent over the firmware loading difficulties caused by a udev change earlier this year. That problem has since been fixed; indeed, it has been fixed twice: once by loading firmware directly from the kernel, and once in udev. But some developers have not forgotten the incident and feel that the current udev maintainers cannot be trusted. In truth, a bit of concern is understandable. The eudev developers point to statements like this one from Lennart Poettering:
Yes, udev on non-systemd systems is in our eyes a dead end, in case
you haven't noticed it yet. I am looking forward to the day when we
can drop that support entirely.
After reading that, it is natural to wonder if the current udev maintainers can truly be trusted to look after the interests of users who do not plan to switch to systemd. From there, it is not too hard to imagine maintaining a fork of udev as an "insurance policy" against misbehavior in the future. That said, a better insurance policy might be to establish oneself as a participating and respected member of the current systemd/udev development community. The strong personalities found there notwithstanding, it is an active community with developers representing a number of distributions. A developer who can work within that group should be able to represent the interests of a distribution like Gentoo nicely while avoiding the costs of maintaining a fork of a crucial utility. And, should that strategy fail, creating a fork of udev remains an option in the future. But nobody can tell free software developers what they can or cannot work on, and nobody is trying to tell the eudev developers that creating their own udev fork is wrong. The situation becomes a bit less clear, though, if eudev is destined to replace udev within Gentoo itself; then Gentoo users may well find they have an opinion on the matter. For now, no such replacement has happened. If it begins to look like that situation could change, one can imagine that the resulting discussion in the Gentoo community will be long and entertaining. (Log in to post comments)
Gentoo's udev fork Posted Nov 21, 2012 21:28 UTC (Wed) by mezcalero (guest, #45103) [Link]
Ahem, it would be nice to mention that there's actually nothing in upstream *udev* that would make split-off /usr impossible or that would even complain about it. Let's clarify this:
a) *udev* doesn't care at all whether /usr is split off.
b) *systemd* will print a *warning* at boot if /usr is not found to be pre-mounted. But that's systemd, not udev. If you don't use systemd, then you will never see this warning. Despite this warning systemd will continue to go on booting, and will in itself not create any problems, as we carefully made sure that the build tree is neatly separated in stuff that goes into / and stuff that goes into /usr if split-off /usr is used, to make this all work. All you need to do for that is use --prefix= and --with-rootprefix= on the configure command line with the right path names.
c) systemd is hence merely the messenger and supports split-off /usr just fine, and if you don't use systemd but only udev, then you won't notice anything at all that has changed.
Hence: the Gentoo Tea Party never used systemd, so they never saw the warning, and even if they had, then it would just have been a warning, and that's it. The split-off /usr thing is hence nothing but a red herring.
And: there's nothing to fix in udev about this. Nothing at all. To make udev itself work fine on split-off /usr requires exactly ZERO patches, because it supports that just fine, out-of-the-box.
Of course, ignoring the warning we print won't win you anything, as you still need to fix the rest of the stack to support split-off /usr. There's simply way too much code in our stack that assumes /usr was already there in early boot. And this is also documented in detail here: http://freedesktop.org/wiki/Software/systemd/separate-usr... -- there's also an non-comprehensive list of packages that are broken in this regard. And again: systemd/udev is not one of those broken packages.
May I ask the editors to update the article to clarify that split-off /usr cannot be fixed by forking udev, because there simply is nothing to fix. In particularly the sentence "Whether a fork like eudev can address those concerns remains to be seen." appears very much misleading to me.
Thanks,
Lennart
Gentoo's udev fork Posted Nov 22, 2012 14:54 UTC (Thu) by tcourbon (subscriber, #60669) [Link]
>> Ahem, it would be nice to mention that there's actually nothing in upstream *udev* that would make split-off /usr impossible or that would even complain about it.
I don't believe this is needed. I understood the article as "the Gentoo councel hope that forking udev will help the distribution to support separate /usr". I may have a flawed English (I'm French (please don't stop to read my comment)) but I believe that Jon merely summarize the meeting minutes and rapport facts.
>> In particularly the sentence "Whether a fork like eudev can address those concerns remains to be seen." appears very much misleading to me.
This sentence appears very ironic to me. But As I said, I'm not a native English speaker.
On a side note, I believe, and I'm pretty sure I'm alone, that if one has not yet understood that systemd and udev aren't the new evil, then nothing Jon could write would bring relief to one's soul.
That said, I appreciate that you take the time to bring some precisions.
(Also the fact the comment was from a mezcalero puzzled me at first, then I read the name at the end. Is it your super hero secret name ?)
Gentoo's udev fork Posted Nov 22, 2012 17:46 UTC (Thu) by smurf (subscriber, #17840) [Link]
>> I understood the article as "the Gentoo councel hope that forking udev will help the distribution to support separate /usr"
Well, to be frank, I understand the situation as "the Gentoo council has no real idea what it intends to accomplish with this split, except for alleviating some generic unease with udev, and thus rehashes some semi-remembered old problems which may or may not actually be udev's fault, or be affected by it in any way".
The split-/usr 'problem' is a case in point. The idea to mount /usr from the initramfs, no further changes needed or questions asked, isn't exactly new.
Gentoo's udev fork Posted Nov 23, 2012 0:06 UTC (Fri) by dirtyepic (subscriber, #30178) [Link]
The Gentoo council decreed from on high a little while back that separate /usr without an initramfs would always remain a supported configuration, which is kind of like when New Mexico legislated that Pluto was still a planet. Reality need not apply.
The situation with upstream is getting a bit desperate, but forking is a ridiculous move. It only ensures that we'll always be left behind, playing catch up.
separate /usr, advantages & disadvantages Posted Nov 27, 2012 9:26 UTC (Tue) by pjm (subscriber, #2080) [Link]
> you still need to fix the rest of the stack to support split-off /usr. There's simply way too much code in our stack that assumes /usr was already there in early boot. And this is also documented in detail here: http://freedesktop.org/wiki/Software/systemd/separate-usr... -- there's also a non-comprehensive list of packages that are broken in this regard.
Not really: that page convinces the reader that there are attempted accesses to /usr before /usr gets mounted, but doesn't identify any actual brokenness beyond saying that the listed packages “[cannot] provide the full set of functionality” — which for all the reader knows might just mean e.g. that the relevant functionality isn't available until /usr is mounted (as I'd guess is the case for the locale example).
In LWN comments (but not in the above-referenced wiki page), someone was more specific and suggested that some USB network or audio devices won't be accessible with separate /usr unless they've been plugged in since /usr was mounted. Even if this example were added to the page, it's not very convincing if the only example offered is specific to (what the reader might consider or guess to be) rare hardware: the reader almost certainly has USB hardware that seems to work fine when /usr is a separate partition, so it might not even be that all USB audio or network devices fail to work.
For the reader who has a separate /usr partition and hasn't noticed the associated brokenness, the page isn't very convincing that separate /usr is broken, or that the brokenness of a separate /usr (that even that page describes as mostly “graceful failures” that “won't become directly visible”) outweighs the rationale traditionally given for separate /usr such as filesystem reliability (“all eggs in one basket” principle) or sharability.
separate /usr, advantages & disadvantages Posted Nov 27, 2012 9:44 UTC (Tue) by Jonno (subscriber, #49613) [Link]
> outweighs the rationale traditionally given for separate /usr such as filesystem reliability (“all eggs in one basket” principle) or sharability.
The nice thing is that you can both eat the cake and have it too, as /usr on a separate filesystem *is* still supported, *provided* you mount it in your initramfs.
That way you get *all* the benefits of a separate /usr partition, without *any* of it's drawbacks, at the small cost of maintaining an initramfs (which your distro tools will likely do for you).
separate /usr, advantages & disadvantages Posted Nov 27, 2012 12:36 UTC (Tue) by pjm (subscriber, #2080) [Link]
Thank you, that's an important omission from that last paragraph. However, the corrected paragraph would still make a similar point given that some people (especially Gentoo users and people who might be attracted to systemd for speed reasons) do prefer not to add an initramfs.
What's initramfs do now? Posted Dec 4, 2012 16:38 UTC (Tue) by alex (subscriber, #1355) [Link]
As I understood it initramfs was a place to store kernel modules that may be needed to mount the rootfs. However there seems to be early init involved these days?
Personally I build my kernel with all the bits it needs to mount rootfs from the start so I'm not sure why I would want or need an initramfs?
What's initramfs do now? Posted Dec 5, 2012 0:28 UTC (Wed) by nix (subscriber, #2304) [Link]
The initramfs is just a cpio archive unpacked into the rootfs (the filesystem / is mounted on top of) and optionally linked into the kernel image. It contains /init, which the kernel runs as PID 1 and which generally finds and overmounts the real root (deleting the contents of the rootfs at the same time, as they are nonswappable and memory is not free) and execs /sbin/init from there. But it doesn't have to do that. It can load modules, it can run udev, it can probe for md or LVM or distributed filesystems or fsck the real / before mounting it rather than doing that gross readonly fsck hack, or do whatever the heck it wants. In particular it can mount *more than one* filesystem. (Heck, mine mounts three and does several bind-mounts as well.)
I've seen initramfses that never exec any real init at all, but run all of userspace from the initramfs (generally a fairly small userspace). I've even seen initramfses that compiled appropriate modules from source and then modprobed them, to make sure they never got out of synch with the running kernel.
initramfses are really powerful. I don't know why people have such a resistance to them. Sure, they're tricky -- the need to wipe the rootfs while overmounting the real /, and the tendency to use a non-glibc libc, makes sure of that -- but they're not actually *scary*. And they're certainly not ugly. They add enormous flexibility to a part of the boot process that used to be completely nonswappable, and particularly if you link the initramfs into the kernel image they can add a lot of robustness, giving you a single kernel image with rescue, recovery, and root-filesystem-finding tools built in and inseparable no matter what weird breakage you do to your filesytem. And they do this without necessarily adding much complexity: my /init is only 172 lines of rarely-changing shell but gives me a rescue shell and md, LVM and NBD booting for all of that.
It's true that dracut is complicated, but it's generic -- complexity is in the nature of a generic solution in a problem space as intricate as this (there are endless ways to find the root filesystem and dracut has to handle all of them). Special-purpose initramfses, or initramfses built for your own use, don't actually need to be complicated or brittle.
What's initramfs do now? Posted Dec 5, 2012 17:03 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> initramfses are really powerful. I don't know why people have such a resistance to them.
you answer this question in the next sentence
> Sure, they're tricky
They are powerful, but if you don't need that power, why pay with the complexity?
This 'extra' copy of things gives you one more place that software can get out of sync (a different version of software on the initramfs than on your main system for example
simple is better, if you don't need a layer of complexity for your systems, it's good to not have it
What's initramfs do now? Posted Dec 5, 2012 17:11 UTC (Wed) by alex (subscriber, #1355) [Link]
Exactly, currently my kernel install is:
make modules_install
Why would I want more complexity to test new kernels?
What's initramfs do now? Posted Dec 5, 2012 20:53 UTC (Wed) by nix (subscriber, #2304) [Link]
Currently my kernel install is
make install modules_install
which I think beats yours by one line. :)
(Yet again: initramfses *do not* need to be installed in separate files -- distros just do that because it makes it easier to ship prepackaged kernels. If you link them into the kernel image, they don't make it harder to test kernels at all: the installed kernel is exactly one file, just as before. A bloody good thing too given the amount of bisection I seem to have been doing recently...)
What's initramfs do now? Posted Dec 5, 2012 21:14 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
but his approach is trivial to put the kernel on a different machine, yours is not.
What's initramfs do now? Posted Dec 5, 2012 22:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Uh? You put the kernel on a different machine by... copying one file (and copying the modules tree if need be). How is that hard?
What's initramfs do now? Posted Dec 5, 2012 23:02 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
plus the system specific initramfs config (raid config, etc)....
What's initramfs do now? Posted Dec 8, 2012 19:10 UTC (Sat) by nix (subscriber, #2304) [Link]
If you need that sort of system-specific config baked into the initramfs, you are doing something wrong. Both mdadm and LVM can scan for things to mount: you should be relying on that, and using config files at most as defaults overrideable on the kernel command line. (A few lines of shell while loop to parse the command line and bingo.)
What's initramfs do now? Posted Dec 5, 2012 20:51 UTC (Wed) by nix (subscriber, #2304) [Link]
Err... the software can't get out of sync because initramfses are built at kernel build time from the software *already on* your system. (Normally. Obviously you can choose to do something else, but that would be strange.)
It lets you customize things that are otherwise uncustomizable -- personally I consider this a good thing. Obviously it's not essential, but it's not some monstrous terrible hugely complex destabilizing thing either. The smallest possible /init is probably less than ten lines of shell script, and most of that is getting a useful /dev to do a mount from.
What's initramfs do now? Posted Dec 5, 2012 22:01 UTC (Wed) by jimparis (subscriber, #38647) [Link]
> Err... the software can't get out of sync because initramfses are built at kernel build time from the software *already on* your system.
How does that keep things in sync? When you update the software on your system, you need to remember to rebuild the initramfs too. Likewise with changing any configuration files that are found in both, like /etc/mdadm/mdadm.conf. I've been bitten by forgetting to run "update-initramfs -u" after changing that file.
What's initramfs do now? Posted Dec 5, 2012 22:19 UTC (Wed) by nix (subscriber, #2304) [Link]
Oh, yeah, sure, if you have config files in an initramfs linked into the kernel, and they change, you're stuffed. I just never ever do that: the only config files in my initramfs are /etc/fstab and /etc/mdadm.conf, and they're just there to default values for the array to activate and root filesystem to mount: a few lines of shell and bingo they're overrideable from the kernel command line. That sort of thing changes much less often than the kernel itself, though, so I consider a linked-in initramfs still preferable because it lets you bisect, test kernels and the like, which is one thing a standalone initramfs or initrd *does* make harder.
separate /usr, advantages & disadvantages Posted Nov 27, 2012 14:54 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I find the argument convincing but maybe I am looking at things a different way. The point as I see it is that booting with a late mounted /usr is not perfect and does not work perfectly in all cases. I think the developers are perfectionists and are deeply unhappy with caveats or corner cases or less than 100% reliability.
Gentoo's udev fork Posted Nov 21, 2012 21:58 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> That said, a better insurance policy might be to establish oneself as a participating and respected member of the current systemd/udev development community.
This sounds nice, but I can't help wondering how welcome people would be in this community after the first time they express the opinion that systemd is pursuing the wrong goals.
There are a lot of people who depend on udev who are either ambiviolent, or opposed to the direction that systemd is going. Expecting those people to be "participating and respected members" on the systemd mailing list would require more restraint than I would expect from both sides.
Gentoo's udev fork Posted Nov 21, 2012 22:02 UTC (Wed) by mezcalero (guest, #45103) [Link]
We are on very good terms with the Ubuntu maintainer of udev, Martin Pitt. In fact he even got commit access and everything. Ubuntu doesn't use systemd, but uses udev just fine, and cooperation with them in regards to udev is just fine.
Gentoo's udev fork Posted Nov 22, 2012 18:03 UTC (Thu) by nix (subscriber, #2304) [Link]
I'm wondering how long they'd last as soon as they said they had anything at all to do with Gentoo. Lennart appears to, ahem, not like Gentoo very much, or people who use it. (Apparently Greg gets some sort of grandfathered-in get-out.)
Gentoo's udev fork Posted Nov 30, 2012 12:12 UTC (Fri) by jospoortvliet (subscriber, #33164) [Link]
as lennart just said, working with the ubuntu udev maintainer is no problem. As i am certain he dislikes ubuntu more than gentoo it is clear that his offer was sincere and your comment not needed. You might not like Lennart but dont accuse him of stuff he doesn't do please, it is childish.
Gentoo's udev fork Posted Nov 22, 2012 2:38 UTC (Thu) by demarchi (subscriber, #67492) [Link]
Regarding kmod, I was really surprised this was a problem at all since we never received a single complaint. If all their worry is about having a library in /usr that's needed by udev, they could have simply installed the library in /lib or in the worst scenario to link statically to libkmod. It would have being solved with 0 patches to either udev or kmod.
Also the way they are "fixing" things is very weird: there is code going and then coming back. Probably with some small changes. This will only make their lives more difficult if they intend to apply patches from the original udev. For example, there's already a ticket for bringing kmod back: https://github.com/gentoo/eudev/issues/3 and another to apply patches from the original udev: https://github.com/gentoo/eudev/issues/18.
Gentoo's udev fork Posted Nov 23, 2012 10:06 UTC (Fri) by Aissen (subscriber, #59976) [Link]
My biggest grief with kmod is the missing modprobe -l. Sure, you could do the same thing with find, but:
- "find /lib/modules/`uname -r`/ -name *.ko" has 240% more characters to type - it requires me to remember the argument to uname.
I don't use modprobe -l programmatically, I just want to list all the installed loadable modules.
Gentoo's udev fork Posted Nov 23, 2012 20:01 UTC (Fri) by nix (subscriber, #2304) [Link]
Speaking as someone who had to write a few hundred lines of code to do the equivalent of modprobe -l using fts() when the deprecation warning came down, it was more than slightly annoying. Yeah, you *can* do it by hand, but isn't the whole point of computers to take that sort of burden away from us?
Gentoo's udev fork Posted Nov 23, 2012 22:13 UTC (Fri) by Thalience (subscriber, #4217) [Link]
Debian (at least) ships /sbin/modprobe as part of the kmod package. If your distribution does not have the (tiny) compatibility wrapper, you should probably open a bug.
Gentoo's udev fork Posted Nov 23, 2012 23:54 UTC (Fri) by ABCD (subscriber, #53650) [Link] The modprobe compatibility wrapper provided by kmod itself does not support the -l option, unlike modprobe from module-init-tools.
Gentoo's udev fork Posted Nov 22, 2012 10:38 UTC (Thu) by linusw (subscriber, #40300) [Link]
Actually Busybox as mentioned in one of the threads does provide its own fork of udev called mdev. So there is already a fork for real tiny embedded systems. But Busybox is forking absolutely everything so I don't know if it counts...
Gentoo's udev fork Posted Nov 22, 2012 18:05 UTC (Thu) by nix (subscriber, #2304) [Link]
mdev isn't a udev fork, it doesn't even count as a reimplementation: it's almost completely different but happens to maintain a (much more simplistic) dynamic /dev.
IMNSHO if you have anything more than the most trivial amount of hotplugging, it's not enough. udev *is* crucial on most modern systems.
Separate /usr works for me.... Posted Nov 22, 2012 12:36 UTC (Thu) by dps (subscriber, #5725) [Link]
I have separate /usr and definitely want to keep it---anything that breaks that is a huge step in the wrong direction. While I can't mount / read only and I *can*, and do, mount /usr read only. /usr is actually on a different physical device too, so just merging with / would require a lot of work.
It would be nice to move further so that /var, /tmp, /home and very few other places are not read only but I appreciate that may be difficult. That said I currently do use systemd.
There are enough tools on / to mount /usr very early in the boot process, so there is no excuse for any init replacement not to cope with that configuration.
Separate /usr works for me.... Posted Nov 22, 2012 13:14 UTC (Thu) by tomegun (subscriber, #56697) [Link]
The suggested and supported way for split /usr to work without any issues is to mount it in your initramfs. This is supported by dracut (fedora) and mkinitcpio (arch) at least, and probably (hopefully) others.
If you do that you are guaranteed for things to keep working also in the future :-)
Separate /usr works for me.... Posted Nov 23, 2012 6:28 UTC (Fri) by drag (subscriber, #31333) [Link]
Bingo.
People complaining about separate /usr are not actually complaining about separate /usr.
They are complaining about having to use a initrd to have a separate /usr.
It's all really incredibly bizzaro and just goes to show that simply ignoring some people is really the best thing to do sometimes.
Separate /usr works for me.... Posted Nov 23, 2012 9:42 UTC (Fri) by nix (subscriber, #2304) [Link]
Not *quite* true. I whined about separate /usr a bit even though I've been using a linked-into-the-kernel initramfs since about six minutes after that became possible, so fixing it was one mount --bind away.
But then I'm a flaming conservative by inclination who hates change :) most people actually had, y'know, *rationales*, such as that they weren't using an initramfs already and setting one up is a bit hair-raising (you can expect to break booting a few times if you're doing anything at all unusual, just as with any other major init script change).
Separate /usr works for me.... Posted Nov 30, 2012 18:53 UTC (Fri) by Wol (guest, #4433) [Link]
AOL.
As a gentoo user, I have a custom kernel with near-enough no modules. Why do I need an initramfs? And when I've mucked about with a system that used it, I got into quite a mess, and needed gentoo to get me out of it.
Yup. People don't like change. I still don't like grub - I'd go back to lilo if it wasn't for everything having moved on and forced me to change...
Cheers,
Separate /usr works for me.... Posted Nov 22, 2012 13:55 UTC (Thu) by jengelh (subscriber, #33263) [Link]
>/usr is actually on a different physical device too, so just merging with / would require a lot of work.
If partition sizes do not need to be changed,, it is really just `mount / /mnt --bind` (avoiding the need for using a rescue boot), then copying /usr to /mnt/usr, removing the mountpoint from fstab and run mkinitrd, is it not?
Gentoo's udev fork Posted Nov 22, 2012 13:19 UTC (Thu) by tomegun (subscriber, #56697) [Link]
Regarding kmod: I don't see why anyone would want to use an alternative modprobe implementation, rather than the awesome libkmod. However, if they do, that's now really simple:
The latest systemd version supports disabling kmod (and hence all loadable modules support). If you do that, you can then easily add back your own version of one udev rules file (80-drivers.rules) to implement module loading with whatever mechanism you prefer (such as calling /sbin/modprobe). No patching of udev needed...
Gentoo's udev fork Posted Nov 22, 2012 14:26 UTC (Thu) by zuki (subscriber, #41808) [Link] Yeah, the latest systemd README shows a list of dependencies that are almost entirely optional (./configure switches and/or autodetection):
REQUIREMENTS:
Linux kernel >= 2.6.39
with devtmpfs
with cgroups (but it's OK to disable all controllers)
optional but strongly recommended: autofs4, ipv6
dbus >= 1.4.0
libcap
libblkid >= 2.20 (from util-linux) (optional)
libkmod >= 5 (optional)
PAM >= 1.1.2 (optional)
libcryptsetup (optional)
libaudit (optional)
libacl (optional)
libattr (optional)
libselinux (optional)
liblzma (optional)
tcpwrappers (optional)
libgcrypt (optional)
libqrencode (optional)
libmicrohttpd (optional)
I'm not really sure what this whole outcry about pulling in dependencies is about.
Wow... Posted Nov 23, 2012 11:40 UTC (Fri) by cesarb (subscriber, #6266) [Link]
> If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined.
[...]
> With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning.
In the same email, no less.
You cannot make stuff like that up.
udev *already* doesn't support non-systemd init systems Posted Dec 17, 2012 8:44 UTC (Mon) by jejb (subscriber, #6654) [Link]
> > Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.
> After reading that, it is natural to wonder if the current udev maintainers can truly be trusted to look after the interests of users who do not plan to switch to systemd. From there, it is not too hard to imagine maintaining a fork of udev as an "insurance policy" against misbehavior in the future.
openSUSE 12.2 is systemd only because the udev version it has: udev-182 has removed support for consolekit (on the rationale that the correct way to do this was integrated into systemd). Without that, you no longer get any desktop devices (like audio or DVD) if you boot udev-182 and sysvinit. So it might be technically true to say you can still boot with udev-182+ and sysvinit, but the system is not functional for a desktop.
|
|||||||||||||