Michael Mol wrote: > On 04/01/2013 03:26 PM, William Hubbs wrote: >> On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote: >>> Nuno J. Silva (aka njsg) wrote: >>>> On 2013-03-31, Dale <rdalek1...@gmail.com> wrote: >>>>> Nuno J. Silva (aka njsg) wrote: >>>>>> On 2013-03-31, Dale <rdalek1...@gmail.com> wrote: >>>>>>> Pandu Poluan wrote: >>>>>>>> >>>>>>>> Since it's obvious that upsteam has this "my way or the highway" >>>>>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the >>>>>>>> same behavior... >>>>>>>> >>>>>>> I synced yesterday and I didn't see the news alert. Last eudev update >>>>>>> was in Feb. so I *guess* not. It seems to be a "udev" thing. That is >>>>>>> why I mentioned eudev to someone else that was having this issue with a >>>>>>> server setup. >>>>>> I'd guess eudev will eventually do the same, although I hope that, it >>>>>> being a separate codebase, makes it easier to adopt some solution like >>>>>> the old rule generator, instead of using udev's approach. >>>>>> >>>>>> The udev upstream may have its issues, but there's actually a point in >>>>>> removing this, the approach there was so far was just a dirty hack. >>>>>> >>>>> >>>>> Thing is, it works for me. The old udev worked, eudev works but I'm not >>>>> sure what hoops I would have to go through to get the new udev working, >>>>> most likely the same ones others here are going through now. For once, >>>>> I'm not having to deal with some broken issue. < knock on wood > >>>>> >>>>> My current uptime is about 190 days. May hit it still but I'm certainly >>>>> hoping I don't. >>>> And, at least now, I have got enough knowledge to know whether it >>>> affects me or not. But the sad thing is that I got most of that >>>> knowledge *after* the first of these versions without the old script was >>>> stabilized. >>>> >>> >>> >>> I switched to eudev when the separate /usr thing popped up. While I am >>> watching this thread and sort of taking mental notes, I'm hoping this is >>> not a eudev thing, even in the future. >> >> You know that both udev and eudev have exactly the same issue with >> separate /usr right? >> >> The problem there isn't in the udev code, but it has to do with what is >> happening in rules that other packages install. > > As I recall, the problem is where the ebuild choses to install the code. > Putting the udev code under /usr forces the issue on systems where it > would otherwise not be an issue. > > Putting the udev code under / avoids that issue, but opens up the system > to the "silently fail" thing upstream liked to use as the basis of > "separate /usr is broken" > > So, there are three conceivable configurations (initramfs notwithstanding): > > 1. With systems which don't require /usr binaries before /usr would be > mounted, separate /usr is not a problem. > > 2. With systems which require /usr binaries for some features before > /usr would be mounted, those features will silently fail. > > 3. With systems which require /usr binaries to mount /usr, all hell > breaks loose. > > Putting the udev code under /usr moves all udev systems from group 2 > into group 3. In a sense, this fixes those systems because the admin is > forced to address the silent failures he was previously unaware of. It > also means pissing off a bunch of people who had features silently > failing...but they probably didn't know or care about those features in > the first place. > > It also moves all systems from group 1 into group 3...which is simply wrong. > > So long as eudev keeps its install path at / instead of /usr, admins in > group 1 will probably be perfectly happy. >
+1 Happy I am. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
