Ben de Groot posted on Wed, 29 Aug 2012 13:06:29 +0800 as excerpted: > For now udev is still usable without systemd, even tho upstream is > making it difficult to build udev separately (and avoid unnecessary > build-time dependencies). Upstream is also unwilling to work with us to > make this easier. > > Despite upstream promises that udev will remain usable stand-alone, > there is a lot of skepticism towards that. So we may find ourselves > faced with the need to use a fork or a replacement for udev. > > Right now the situation is in flux, so we are basically waiting to see > how things will develop.
Yours and Luca's summaries LGTM. Two comments/observations and one question, tho. Question first, at the top: Question: For those who have actually built it, what *IS* the full systemd relative merge-time, and how does that compare to that of pre-merge udev? I doubt that most people consider udev's stand-alone build-time a big issue. It's not like a gcc update, or firefox, or the classic example, OOo/LO. Building/installing udev has always been relatively trivial. Just how much worse are we talking if we DO end up having to build nearly all of systemd, only to throw out most of it, just keeping udev? If it's just 50% more than udev by itself, or even double, while having to build all of systemd just to throw out most of it is irksum in principle, in practice, for most, it wouldn't be a big deal. (Yes, there's the underpowered minor archs where it would be, but even there, relatively...) Ten times the build/install time, however, and it's rather more of an issue. 20 or 50 times, and it's a much *BIGGGER* issue. So in practice, just what are the sorts of times, relative to stand-alone- build udev, we're talking about? In all this discussion, what, hundreds of posts by now?, I've not seen ANYONE actually ask, let alone answer, THAT. But it would seem to be a rather important question... Comments/observations (mostly rehash for those who read the other thread, feel free to skip to the next post): 1) On gentoo, "usable standalone" by definition means reasonably buildable, standalone, ideally without going to extreme lengths via complex and exotic ebuild/eclasses to do it. That's rather different than upstream's definition of "usable standalone", which they did promise, but which to them simply means the already built binary (as found in systemd-based distros for use in their initr*s before switching to real-root, where systemd is found, that being the specific example they gave) will continue to function on its own -- they have in fact specifically stated that they have absolutely NO interest in keeping it / buildable/ stand-alone, or in cooperation with distros like gentoo who find that IS in their interest. Given that difference in definition for "usable standalone", it's with good reason that gentooers generally view that upstream claim with extreme skepticism. 2) But my primary point in an earlier thread on the topic still stands. Gentoo's current udev/openrc default simply can't and won't be changed on a dime. Even if gentoo chose to do it today and the project was given extreme priority, we're looking at at LEAST a year, more like two. And by 2-3 years out, if Linux/FLOSS history is any guide, the whole ecosystem will look different, and we'll have a whole list of new changes and challenges to worry about, so somewhere between 3-5 years out, the picture simply gets way too fuzzy to predict any more, and throwing the dice has about as good a chance. So with no plans to immediately change gentoo's position, it's a pretty safe bet that any changes of that size that WOULD occur are safely out beyond that three-year horizon where things start getting fuzzy, and beyond that, it's anyone's guess. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
