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.
signature.asc
Description: OpenPGP digital signature
