Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

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 <rdalek1967@×××××.com> wrote:
>>>> Nuno J. Silva (aka njsg) wrote:
>>>>> On 2013-03-31, Dale <rdalek1967@×××××.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.