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

[Dale]

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 <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.
>


+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!