Moving from old udev to eudev

classic Classic list List threaded Threaded
108 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
On 02/08/13 04:01, Walter Dnes wrote:

> On Fri, Aug 02, 2013 at 02:42:36AM +0300, Samuli Suominen wrote
>
>> nope, you just believed all the FUD there has been out there.  i've said
>> it many times, and i'll say it again:
>>
>> the only real different is USE="rule-generator" and that's it
>>
>> and sys-fs/eudev is constantly out of date and haven't developed any
>> features of their own
>
>    What are the "new features"?  What have Lennart/Kay broken recently?
> First it was firmware loading in udev, which got them reamed out by
> Linus.  Then it was (un)predictable network interface names.  Gentoo is
> not Facebook http://www.geek.com/news/mark-zuckerberg-says-you-need-to-move-fast-and-break-things-922432/
>
>> The key to the real innovation, says Zuckerberg, is to "move fast
>> and break things."
>

Huh? USE="firmware-loader" is optional and enabled by default in sys-fs/udev
Futhermore predictable network interface names work as designed, not a
single valid bug filed about them.

Stop spreading FUD.

Looking forward to lastrite sys-fs/eudev just like
sys-apps/module-init-tools already was removed as unnecessary later on.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Dale-46
Samuli Suominen wrote:

>
> Huh? USE="firmware-loader" is optional and enabled by default in
> sys-fs/udev
> Futhermore predictable network interface names work as designed, not a
> single valid bug filed about them.
>
> Stop spreading FUD.
>
> Looking forward to lastrite sys-fs/eudev just like
> sys-apps/module-init-tools already was removed as unnecessary later on.
>
>

So your real agenda is to kill eudev?  Maybe it is you that is spreading
FUD instead of others.  Like others have said, udev was going to cause
issues, eudev has yet to cause any.

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
On 02/08/13 05:48, Dale wrote:

> Samuli Suominen wrote:
>>
>> Huh? USE="firmware-loader" is optional and enabled by default in
>> sys-fs/udev
>> Futhermore predictable network interface names work as designed, not a
>> single valid bug filed about them.
>>
>> Stop spreading FUD.
>>
>> Looking forward to lastrite sys-fs/eudev just like
>> sys-apps/module-init-tools already was removed as unnecessary later on.
>
> So your real agenda is to kill eudev?  Maybe it is you that is spreading
> FUD instead of others.  Like others have said, udev was going to cause
> issues, eudev has yet to cause any.

Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't
bring in anything useful, and it reintroduced old bugs from old version
of udev, as well as adds confusing to users.
And no, sys-fs/udev doesn't have issues, in fact, less than what
sys-fs/eudev has.
Like said earlier, the bugs assigned to [hidden email] apply also to
sys-fs/eudev and they have even more in their github ticketing system.
And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
it doesn't fall too much behind, which adds double work unnecessarily.
They don't keep it up-to-date on their own without prodding.

Really, this is how it has went right from the start and the double work
and user confusion needs to stop.

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Dale-46
Samuli Suominen wrote:

> On 02/08/13 05:48, Dale wrote:
>> Samuli Suominen wrote:
>>>
>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>> sys-fs/udev
>>> Futhermore predictable network interface names work as designed, not a
>>> single valid bug filed about them.
>>>
>>> Stop spreading FUD.
>>>
>>> Looking forward to lastrite sys-fs/eudev just like
>>> sys-apps/module-init-tools already was removed as unnecessary later on.
>>
>> So your real agenda is to kill eudev?  Maybe it is you that is spreading
>> FUD instead of others.  Like others have said, udev was going to cause
>> issues, eudev has yet to cause any.
>
> Yes, absolutely sys-fs/eudev should be punted from tree since it
> doesn't bring in anything useful, and it reintroduced old bugs from
> old version of udev, as well as adds confusing to users.
> And no, sys-fs/udev doesn't have issues, in fact, less than what
> sys-fs/eudev has.
> Like said earlier, the bugs assigned to [hidden email] apply also to
> sys-fs/eudev and they have even more in their github ticketing system.
> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
> it doesn't fall too much behind, which adds double work unnecessarily.
> They don't keep it up-to-date on their own without prodding.
>
> Really, this is how it has went right from the start and the double
> work and user confusion needs to stop.
>
> - Samuli
>
>

So any bug that udev has eudev has too?  Then with that logic, udev is
just as unstable as eudev.  You claim eudev has a bug that udev doesn't,
let's see them.  Based on your posts, there should be plenty of them.
Funny I haven't ran into any of them yet tho.

Here is the deal OK.  Udev went in a direction I do NOT like.  I CHOSE
not to use it and plan to not use it.  I PREFER eudev whether you like
that decision or not.  I also plan to use eudev as long as it serves my
needs as I suspect others will as well.  You can preach FUD all you want
but it works here for me and as others have posted, it works fine for
them.  The OP asked for assistance in switching to eudev not for you to
second guess their choice or to second guess anyone else who chooses to
use it.

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Bill Kenworthy
In reply to this post by Samuli Suominen-4
On 02/08/13 11:01, Samuli Suominen wrote:

> On 02/08/13 05:48, Dale wrote:
>> Samuli Suominen wrote:
>>>
>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>> sys-fs/udev
>>> Futhermore predictable network interface names work as designed, not a
>>> single valid bug filed about them.
>>>
>>> Stop spreading FUD.
>>>
>>> Looking forward to lastrite sys-fs/eudev just like
>>> sys-apps/module-init-tools already was removed as unnecessary later on.
>>
>> So your real agenda is to kill eudev?  Maybe it is you that is spreading
>> FUD instead of others.  Like others have said, udev was going to cause
>> issues, eudev has yet to cause any.
>
> Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't
> bring in anything useful, and it reintroduced old bugs from old version
> of udev, as well as adds confusing to users.
> And no, sys-fs/udev doesn't have issues, in fact, less than what
> sys-fs/eudev has.
> Like said earlier, the bugs assigned to [hidden email] apply also to
> sys-fs/eudev and they have even more in their github ticketing system.
> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
> it doesn't fall too much behind, which adds double work unnecessarily.
> They don't keep it up-to-date on their own without prodding.
>
> Really, this is how it has went right from the start and the double work
> and user confusion needs to stop.
>
> - Samuli
>

From my point of view, its udev/systemd that should be punted - what
about user choice? - Ive decided I no longer want to buy into the flaky,
unusable systems gnome3 and udev/systemd integration caused me even
though I didn't have systemd installed, so why should I be forced to?  A
group have come up with a way to keep my systems running properly
without those packages and its working better than udev ever has for me ...

BillK



Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
In reply to this post by Dale-46
On 02/08/13 06:14, Dale wrote:

> Samuli Suominen wrote:
>> On 02/08/13 05:48, Dale wrote:
>>> Samuli Suominen wrote:
>>>>
>>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>>> sys-fs/udev
>>>> Futhermore predictable network interface names work as designed, not a
>>>> single valid bug filed about them.
>>>>
>>>> Stop spreading FUD.
>>>>
>>>> Looking forward to lastrite sys-fs/eudev just like
>>>> sys-apps/module-init-tools already was removed as unnecessary later on.
>>>
>>> So your real agenda is to kill eudev?  Maybe it is you that is spreading
>>> FUD instead of others.  Like others have said, udev was going to cause
>>> issues, eudev has yet to cause any.
>>
>> Yes, absolutely sys-fs/eudev should be punted from tree since it
>> doesn't bring in anything useful, and it reintroduced old bugs from
>> old version of udev, as well as adds confusing to users.
>> And no, sys-fs/udev doesn't have issues, in fact, less than what
>> sys-fs/eudev has.
>> Like said earlier, the bugs assigned to [hidden email] apply also to
>> sys-fs/eudev and they have even more in their github ticketing system.
>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
>> it doesn't fall too much behind, which adds double work unnecessarily.
>> They don't keep it up-to-date on their own without prodding.
>>
>> Really, this is how it has went right from the start and the double
>> work and user confusion needs to stop.
>>
>> - Samuli
>>
>>
>
> So any bug that udev has eudev has too?

Yes, because eudev is copying the upstream code over from udev.

> Then with that logic, udev is just as unstable as eudev.

Except it isn't because as already explained, eudev makes additional
changes on top of udev changes.

> You claim eudev has a bug that udev doesn't,

Which is true.

> let's see them.  Based on your posts, there should be plenty of them.
> Funny I haven't ran into any of them yet tho.

I'm not suprised, because the current status is so similar between udev
vs. eudev. Only regression that's known currently is
IUSE="+rule-generator" that doesn't do it's job correctly and
70-persistent-net.rules it is generating can't be trusted.

> Here is the deal OK.  Udev went in a direction I do NOT like.

What direction is that? Everything same is in sys-fs/udev than is in
sys-fs/eudev, except the buggy rule-generator.

> I CHOSE not to use it and plan to not use it.  I PREFER eudev whether you like
> that decision or not.  I also plan to use eudev as long as it serves my
> needs as I suspect others will as well.  You can preach FUD all you want
> but it works here for me and as others have posted, it works fine for
> them.  The OP asked for assistance in switching to eudev not for you to
> second guess their choice or to second guess anyone else who chooses to
> use it.

I feel pity for you, too bad the eudev in tree causes such level of
ignorance.

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Graham Murray
In reply to this post by Samuli Suominen-4
Samuli Suominen <[hidden email]> writes:

> Futhermore predictable network interface names work as designed, not a
> single valid bug filed about them.
>
> Stop spreading FUD.

In what way are network interface names predictable? A new system
arrives on your desk, what is the name of the first (or only) Ethernet
interface?  Under the 'old' system, you know it will be 'eth0'[1]. With
the new scheme you do not know until the system is booted. The interface
name is (mostly) consistent once you know it, but it is not predictable.

[1] On a multi-interface system you may not have known which physical
port was eth0, but you knew that one of them was.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Dale-46
In reply to this post by Samuli Suominen-4
Samuli Suominen wrote:

> On 02/08/13 06:14, Dale wrote:
>> Samuli Suominen wrote:
>>> On 02/08/13 05:48, Dale wrote:
>>>> Samuli Suominen wrote:
>>>>>
>>>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>>>> sys-fs/udev
>>>>> Futhermore predictable network interface names work as designed,
>>>>> not a
>>>>> single valid bug filed about them.
>>>>>
>>>>> Stop spreading FUD.
>>>>>
>>>>> Looking forward to lastrite sys-fs/eudev just like
>>>>> sys-apps/module-init-tools already was removed as unnecessary
>>>>> later on.
>>>>
>>>> So your real agenda is to kill eudev?  Maybe it is you that is
>>>> spreading
>>>> FUD instead of others.  Like others have said, udev was going to cause
>>>> issues, eudev has yet to cause any.
>>>
>>> Yes, absolutely sys-fs/eudev should be punted from tree since it
>>> doesn't bring in anything useful, and it reintroduced old bugs from
>>> old version of udev, as well as adds confusing to users.
>>> And no, sys-fs/udev doesn't have issues, in fact, less than what
>>> sys-fs/eudev has.
>>> Like said earlier, the bugs assigned to [hidden email] apply also to
>>> sys-fs/eudev and they have even more in their github ticketing system.
>>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
>>> it doesn't fall too much behind, which adds double work unnecessarily.
>>> They don't keep it up-to-date on their own without prodding.
>>>
>>> Really, this is how it has went right from the start and the double
>>> work and user confusion needs to stop.
>>>
>>> - Samuli
>>>
>>>
>>
>> So any bug that udev has eudev has too?
>
> Yes, because eudev is copying the upstream code over from udev.
>
>> Then with that logic, udev is just as unstable as eudev.
>
> Except it isn't because as already explained, eudev makes additional
> changes on top of udev changes.
>
>> You claim eudev has a bug that udev doesn't,
>
> Which is true.

Let's see them.   I'll help you:

https://bugs.gentoo.org/buglist.cgi?quicksearch=eudev&list_id=1920856


>
>> let's see them.  Based on your posts, there should be plenty of them.
>> Funny I haven't ran into any of them yet tho.
>
> I'm not suprised, because the current status is so similar between
> udev vs. eudev. Only regression that's known currently is
> IUSE="+rule-generator" that doesn't do it's job correctly and
> 70-persistent-net.rules it is generating can't be trusted.

So still no links to any bug reports that are eudev specific huh?  See
above.


>
>> Here is the deal OK.  Udev went in a direction I do NOT like.
>
> What direction is that? Everything same is in sys-fs/udev than is in
> sys-fs/eudev, except the buggy rule-generator.
>
>> I CHOSE not to use it and plan to not use it.  I PREFER eudev whether
>> you like
>> that decision or not.  I also plan to use eudev as long as it serves my
>> needs as I suspect others will as well.  You can preach FUD all you want
>> but it works here for me and as others have posted, it works fine for
>> them.  The OP asked for assistance in switching to eudev not for you to
>> second guess their choice or to second guess anyone else who chooses to
>> use it.
>
> I feel pity for you, too bad the eudev in tree causes such level of
> ignorance.
>
> - Samuli
>
>


Here is some FUD for you.  Eudev just left beta.  From the eudev changelog.

*eudev-1.2 (01 Aug 2013)

  01 Aug 2013; Ian Stakenvicius <[hidden email]> +eudev-1.2.ebuild,
  -eudev-1.2_beta.ebuild:
  version bump, remove beta


Just keep telling yourself this stuff and maybe one day you will
convince someone besides yourself.  In the meantime, others and myself
will continue to use eudev, whether you agree or not.  Keep the pity for
yourself OK.  I don't need it.

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
On 02/08/13 08:28, Dale wrote:

> Samuli Suominen wrote:
>> On 02/08/13 06:14, Dale wrote:
>>> Samuli Suominen wrote:
>>>> On 02/08/13 05:48, Dale wrote:
>>>>> Samuli Suominen wrote:
>>>>>>
>>>>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>>>>> sys-fs/udev
>>>>>> Futhermore predictable network interface names work as designed,
>>>>>> not a
>>>>>> single valid bug filed about them.
>>>>>>
>>>>>> Stop spreading FUD.
>>>>>>
>>>>>> Looking forward to lastrite sys-fs/eudev just like
>>>>>> sys-apps/module-init-tools already was removed as unnecessary
>>>>>> later on.
>>>>>
>>>>> So your real agenda is to kill eudev?  Maybe it is you that is
>>>>> spreading
>>>>> FUD instead of others.  Like others have said, udev was going to cause
>>>>> issues, eudev has yet to cause any.
>>>>
>>>> Yes, absolutely sys-fs/eudev should be punted from tree since it
>>>> doesn't bring in anything useful, and it reintroduced old bugs from
>>>> old version of udev, as well as adds confusing to users.
>>>> And no, sys-fs/udev doesn't have issues, in fact, less than what
>>>> sys-fs/eudev has.
>>>> Like said earlier, the bugs assigned to [hidden email] apply also to
>>>> sys-fs/eudev and they have even more in their github ticketing system.
>>>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
>>>> it doesn't fall too much behind, which adds double work unnecessarily.
>>>> They don't keep it up-to-date on their own without prodding.
>>>>
>>>> Really, this is how it has went right from the start and the double
>>>> work and user confusion needs to stop.
>>>>
>>>> - Samuli
>>>>
>>>>
>>>
>>> So any bug that udev has eudev has too?
>>
>> Yes, because eudev is copying the upstream code over from udev.
>>
>>> Then with that logic, udev is just as unstable as eudev.
>>
>> Except it isn't because as already explained, eudev makes additional
>> changes on top of udev changes.
>>
>>> You claim eudev has a bug that udev doesn't,
>>
>> Which is true.
>
> Let's see them.   I'll help you:
>
> https://bugs.gentoo.org/buglist.cgi?quicksearch=eudev&list_id=1920856

Help yourself instead and use correct search parameters, like below...

>>
>>> let's see them.  Based on your posts, there should be plenty of them.
>>> Funny I haven't ran into any of them yet tho.
>>
>> I'm not suprised, because the current status is so similar between
>> udev vs. eudev. Only regression that's known currently is
>> IUSE="+rule-generator" that doesn't do it's job correctly and
>> 70-persistent-net.rules it is generating can't be trusted.
>
> So still no links to any bug reports that are eudev specific huh?  See
> above.

Search bugzilla for [hidden email] and 90% of them apply also to
eudev.
Search bugzilla for [hidden email] and those all apply.
Search eudev github page Tickets and those all apply.

>>
>>> Here is the deal OK.  Udev went in a direction I do NOT like.
>>
>> What direction is that? Everything same is in sys-fs/udev than is in
>> sys-fs/eudev, except the buggy rule-generator.
>>
>>> I CHOSE not to use it and plan to not use it.  I PREFER eudev whether
>>> you like
>>> that decision or not.  I also plan to use eudev as long as it serves my
>>> needs as I suspect others will as well.  You can preach FUD all you want
>>> but it works here for me and as others have posted, it works fine for
>>> them.  The OP asked for assistance in switching to eudev not for you to
>>> second guess their choice or to second guess anyone else who chooses to
>>> use it.
>>
>> I feel pity for you, too bad the eudev in tree causes such level of
>> ignorance.
>>
>> - Samuli
>>
>>
>
>
> Here is some FUD for you.  Eudev just left beta.  From the eudev changelog.
>
> *eudev-1.2 (01 Aug 2013)
>
>    01 Aug 2013; Ian Stakenvicius <[hidden email]> +eudev-1.2.ebuild,
>    -eudev-1.2_beta.ebuild:
>    version bump, remove beta

And how did they get there?
By udev maintainers forcing them to upgrade to the new keymap hwdb which
required version to be raised to up-to-par with udev-206.

Anyway, have fun with pointless udev fork which will never be the
default. I don't care if you don't want the system up-to-par with
production level system. :-)

- Samuli

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alon Bar-Lev-2
In reply to this post by Dale-46
On Fri, Aug 2, 2013 at 6:14 AM, Dale <[hidden email]> wrote:

> Samuli Suominen wrote:
>> On 02/08/13 05:48, Dale wrote:
>>> Samuli Suominen wrote:
>>>>
>>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>>> sys-fs/udev
>>>> Futhermore predictable network interface names work as designed, not a
>>>> single valid bug filed about them.
>>>>
>>>> Stop spreading FUD.
>>>>
>>>> Looking forward to lastrite sys-fs/eudev just like
>>>> sys-apps/module-init-tools already was removed as unnecessary later on.
>>>
>>> So your real agenda is to kill eudev?  Maybe it is you that is spreading
>>> FUD instead of others.  Like others have said, udev was going to cause
>>> issues, eudev has yet to cause any.
>>
>> Yes, absolutely sys-fs/eudev should be punted from tree since it
>> doesn't bring in anything useful, and it reintroduced old bugs from
>> old version of udev, as well as adds confusing to users.
>> And no, sys-fs/udev doesn't have issues, in fact, less than what
>> sys-fs/eudev has.
>> Like said earlier, the bugs assigned to [hidden email] apply also to
>> sys-fs/eudev and they have even more in their github ticketing system.
>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
>> it doesn't fall too much behind, which adds double work unnecessarily.
>> They don't keep it up-to-date on their own without prodding.
>>
>> Really, this is how it has went right from the start and the double
>> work and user confusion needs to stop.
>>
>> - Samuli
>>
>>
>
> So any bug that udev has eudev has too?  Then with that logic, udev is
> just as unstable as eudev.  You claim eudev has a bug that udev doesn't,
> let's see them.  Based on your posts, there should be plenty of them.
> Funny I haven't ran into any of them yet tho.
>
> Here is the deal OK.  Udev went in a direction I do NOT like.  I CHOSE
> not to use it and plan to not use it.  I PREFER eudev whether you like
> that decision or not.  I also plan to use eudev as long as it serves my
> needs as I suspect others will as well.  You can preach FUD all you want
> but it works here for me and as others have posted, it works fine for
> them.  The OP asked for assistance in switching to eudev not for you to
> second guess their choice or to second guess anyone else who chooses to
> use it.

I join this statement!
Thanks!

>
> Dale
>
> :-)  :-)
>
> --
> I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alon Bar-Lev-2
In reply to this post by Bill Kenworthy
On Fri, Aug 2, 2013 at 6:17 AM, William Kenworthy <[hidden email]> wrote:

> On 02/08/13 11:01, Samuli Suominen wrote:
>> On 02/08/13 05:48, Dale wrote:
>>> Samuli Suominen wrote:
>>>>
>>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>>> sys-fs/udev
>>>> Futhermore predictable network interface names work as designed, not a
>>>> single valid bug filed about them.
>>>>
>>>> Stop spreading FUD.
>>>>
>>>> Looking forward to lastrite sys-fs/eudev just like
>>>> sys-apps/module-init-tools already was removed as unnecessary later on.
>>>
>>> So your real agenda is to kill eudev?  Maybe it is you that is spreading
>>> FUD instead of others.  Like others have said, udev was going to cause
>>> issues, eudev has yet to cause any.
>>
>> Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't
>> bring in anything useful, and it reintroduced old bugs from old version
>> of udev, as well as adds confusing to users.
>> And no, sys-fs/udev doesn't have issues, in fact, less than what
>> sys-fs/eudev has.
>> Like said earlier, the bugs assigned to [hidden email] apply also to
>> sys-fs/eudev and they have even more in their github ticketing system.
>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
>> it doesn't fall too much behind, which adds double work unnecessarily.
>> They don't keep it up-to-date on their own without prodding.
>>
>> Really, this is how it has went right from the start and the double work
>> and user confusion needs to stop.
>>
>> - Samuli
>>
>
> From my point of view, its udev/systemd that should be punted - what
> about user choice? - Ive decided I no longer want to buy into the flaky,
> unusable systems gnome3 and udev/systemd integration caused me even
> though I didn't have systemd installed, so why should I be forced to?  A
> group have come up with a way to keep my systems running properly
> without those packages and its working better than udev ever has for me ...
>
> BillK
>

I second this statement!
The monolithic nature of the systemd maintainer is something that
should be banned (dependency, which requires dependency recursively
until you end up with no choice and medium quality components).
There was no reason to merge the code base of udev to any other code base.
There was no reason to kill backward compatibility.
Well, you all know the reason of why eudev was established.
I am very happy with eudev, had zero issues.

Thanks!
Alon Bar-Lev

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Samuli Suominen-4
On 02/08/13 09:06, Alon Bar-Lev wrote:

> On Fri, Aug 2, 2013 at 6:17 AM, William Kenworthy <[hidden email]> wrote:
>> On 02/08/13 11:01, Samuli Suominen wrote:
>>> On 02/08/13 05:48, Dale wrote:
>>>> Samuli Suominen wrote:
>>>>>
>>>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>>>> sys-fs/udev
>>>>> Futhermore predictable network interface names work as designed, not a
>>>>> single valid bug filed about them.
>>>>>
>>>>> Stop spreading FUD.
>>>>>
>>>>> Looking forward to lastrite sys-fs/eudev just like
>>>>> sys-apps/module-init-tools already was removed as unnecessary later on.
>>>>
>>>> So your real agenda is to kill eudev?  Maybe it is you that is spreading
>>>> FUD instead of others.  Like others have said, udev was going to cause
>>>> issues, eudev has yet to cause any.
>>>
>>> Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't
>>> bring in anything useful, and it reintroduced old bugs from old version
>>> of udev, as well as adds confusing to users.
>>> And no, sys-fs/udev doesn't have issues, in fact, less than what
>>> sys-fs/eudev has.
>>> Like said earlier, the bugs assigned to [hidden email] apply also to
>>> sys-fs/eudev and they have even more in their github ticketing system.
>>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
>>> it doesn't fall too much behind, which adds double work unnecessarily.
>>> They don't keep it up-to-date on their own without prodding.
>>>
>>> Really, this is how it has went right from the start and the double work
>>> and user confusion needs to stop.
>>>
>>> - Samuli
>>>
>>
>>  From my point of view, its udev/systemd that should be punted - what
>> about user choice? - Ive decided I no longer want to buy into the flaky,
>> unusable systems gnome3 and udev/systemd integration caused me even
>> though I didn't have systemd installed, so why should I be forced to?  A
>> group have come up with a way to keep my systems running properly
>> without those packages and its working better than udev ever has for me ...
>>
>> BillK
>>
>
> I second this statement!
> The monolithic nature of the systemd maintainer is something that
> should be banned (dependency, which requires dependency recursively
> until you end up with no choice and medium quality components).
> There was no reason to merge the code base of udev to any other code base.
> There was no reason to kill backward compatibility.

FUD again. The backwards compability is still all there and udev can be
built standalone and ran standalone.
And on the contrary, there was no need for sys-fs/eudev to remove
support for sys-fs/systemd when it could have supported both
sys-apps/systemd and sys-apps/openrc like sys-fs/udev does without issues.

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alon Bar-Lev-2
On Fri, Aug 2, 2013 at 10:03 AM, Samuli Suominen <[hidden email]> wrote:

> On 02/08/13 09:06, Alon Bar-Lev wrote:
>>
>> On Fri, Aug 2, 2013 at 6:17 AM, William Kenworthy <[hidden email]>
>> wrote:
>>>
>>> On 02/08/13 11:01, Samuli Suominen wrote:
>>>>
>>>> On 02/08/13 05:48, Dale wrote:
>>>>>
>>>>> Samuli Suominen wrote:
>>>>>>
>>>>>>
>>>>>> Huh? USE="firmware-loader" is optional and enabled by default in
>>>>>> sys-fs/udev
>>>>>> Futhermore predictable network interface names work as designed, not a
>>>>>> single valid bug filed about them.
>>>>>>
>>>>>> Stop spreading FUD.
>>>>>>
>>>>>> Looking forward to lastrite sys-fs/eudev just like
>>>>>> sys-apps/module-init-tools already was removed as unnecessary later
>>>>>> on.
>>>>>
>>>>>
>>>>> So your real agenda is to kill eudev?  Maybe it is you that is
>>>>> spreading
>>>>> FUD instead of others.  Like others have said, udev was going to cause
>>>>> issues, eudev has yet to cause any.
>>>>
>>>>
>>>> Yes, absolutely sys-fs/eudev should be punted from tree since it doesn't
>>>> bring in anything useful, and it reintroduced old bugs from old version
>>>> of udev, as well as adds confusing to users.
>>>> And no, sys-fs/udev doesn't have issues, in fact, less than what
>>>> sys-fs/eudev has.
>>>> Like said earlier, the bugs assigned to [hidden email] apply also to
>>>> sys-fs/eudev and they have even more in their github ticketing system.
>>>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so
>>>> it doesn't fall too much behind, which adds double work unnecessarily.
>>>> They don't keep it up-to-date on their own without prodding.
>>>>
>>>> Really, this is how it has went right from the start and the double work
>>>> and user confusion needs to stop.
>>>>
>>>> - Samuli
>>>>
>>>
>>>  From my point of view, its udev/systemd that should be punted - what
>>> about user choice? - Ive decided I no longer want to buy into the flaky,
>>> unusable systems gnome3 and udev/systemd integration caused me even
>>> though I didn't have systemd installed, so why should I be forced to?  A
>>> group have come up with a way to keep my systems running properly
>>> without those packages and its working better than udev ever has for me
>>> ...
>>>
>>> BillK
>>>
>>
>> I second this statement!
>> The monolithic nature of the systemd maintainer is something that
>> should be banned (dependency, which requires dependency recursively
>> until you end up with no choice and medium quality components).
>> There was no reason to merge the code base of udev to any other code base.
>> There was no reason to kill backward compatibility.
>
>
> FUD again. The backwards compability is still all there and udev can be
> built standalone and ran standalone.
> And on the contrary, there was no need for sys-fs/eudev to remove support
> for sys-fs/systemd when it could have supported both sys-apps/systemd and
> sys-apps/openrc like sys-fs/udev does without issues.
>

No FUD... it can be currently with some patches, this is against
agenda of upstream... but you are right it *CAN* be done... with
effort and modifications.

In future, even that "support" may be removed because of upstream agenda.

I appreciate the effort of creating standalone udev project, I do not
care if this is udev fork or mdev or anything else that provide
userspace device management, that is free of commercial agenda and the
dependency lock-in.

As long as there is alternative to systemd upstream I will endorse it
and use it to help the relevant upstream to improve his software.

Regards,
Alon

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Steven J. Long
In reply to this post by Samuli Suominen-4
Samuli Suominen wrote:
> Futhermore predictable network interface names work as designed,

Unfortunately the "design" is crap.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Steven J. Long
In reply to this post by Samuli Suominen-4
Samuli Suominen wrote:
> FUD again. The backwards compability is still all there and udev can be
> built standalone and ran standalone.

Sorry I'm going to call "bullshit" on this one.

You know damn well "upstream" moved udev into systemd, promising everyone it would
be possible to continue to build just udev, and then changed that with weasel words
into "build everything and extract udev".

So you cannot "build udev standalone" any more, as you state. You have to build systemd
and then extract the udev stuff you actually want.

You don't like other projects bundling dependencies, but somehow it's ok for systemd.
Utter tripe.

> And on the contrary, there was no need for sys-fs/eudev to remove
> support for sys-fs/systemd when it could have supported both
> sys-apps/systemd and sys-apps/openrc like sys-fs/udev does without issues.

Huh? WTF would be the point, when systemd bundles udev?

We already have loads of people on the forums having issues with conflicts between
sys-apps/systemd and sys-fs/udev, so again your point is total nonsense.

None of which detracts from for your sterling work on Gentoo, and the support you provide
to users on various media.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
In reply to this post by Dale-46
On 2013-08-01 5:41 PM, Dale <[hidden email]> wrote:
> When the version of udev came out that was said to require a init thingy
> or /usr on /, that is when I switched to eudev.  I haven't used the
> newer versions of udev.   I do have this in my kernel config tho:
>
> root@fireball / # cat /usr/src/linux/.config | grep -i CONFIG_DEVTMPFS
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> root@fireball / #

Thanks Dale... looks easy enough...

But what about removing the udev-postmount init script? I guess that is
the last question I need answered before jumping down the rabbit hole
Sunday...

Thanks again to all who responded...

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

tanstaafl-2
In reply to this post by Bill Kenworthy
On 2013-08-01 7:27 PM, William Kenworthy <[hidden email]> wrote:

> Something like
>
> olympus ~ # cat /etc/portage/package.mask
>> =sys-fs/udev-180
> ...
> olympus ~ #
>
> olympus ~ # grep udev /etc/portage/package.keywords
> sys-fs/eudev ~amd64
> =virtual/udev-206 ~amd64
> olympus ~ #
>
> unmerge everything udev && emerge eudev
>
> its been much less fuss and bother than trying to stick with the udev
> machinations - I have maybe 15 machines and vm's running eudev, no udev
> ... :)

Thanks Bill...

Two questions...

1. Why =virtual/udev-206 ~amd64 instead of virtual/udev ~amd64 ?

and

2. Did you remove the udev-postmount init script?

Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Dale-46
In reply to this post by Samuli Suominen-4
Samuli Suominen wrote:

> On 02/08/13 08:28, Dale wrote:
>> Samuli Suominen wrote:
>>>
>>> Except it isn't because as already explained, eudev makes additional
>>> changes on top of udev changes.
>>>
>>>
>>> Which is true.
>>
>> Let's see them.   I'll help you:
>>
>> https://bugs.gentoo.org/buglist.cgi?quicksearch=eudev&list_id=1920856
>
> Help yourself instead and use correct search parameters, like below...
>
>>>
>>>> let's see them.  Based on your posts, there should be plenty of them.
>>>> Funny I haven't ran into any of them yet tho.
>>>
>>> I'm not suprised, because the current status is so similar between
>>> udev vs. eudev. Only regression that's known currently is
>>> IUSE="+rule-generator" that doesn't do it's job correctly and
>>> 70-persistent-net.rules it is generating can't be trusted.
>>
>> So still no links to any bug reports that are eudev specific huh?  See
>> above.
>
> Search bugzilla for [hidden email] and 90% of them apply also to
> eudev.
> Search bugzilla for [hidden email] and those all apply.
> Search eudev github page Tickets and those all apply.

You mean like this:

https://bugs.gentoo.org/buglist.cgi?quicksearch=eudev%40gentoo.org&list_id=1921198


Results:

"Zarro Boogs found."

No open bugs!!  When I look for open bugs for a package, I look for the
package name itself.  That has worked for ages and my search actually
did turn up one stable request where yours didn't.

>
>>>
>>>> Here is the deal OK.  Udev went in a direction I do NOT like.
>>>
>>> What direction is that? Everything same is in sys-fs/udev than is in
>>> sys-fs/eudev, except the buggy rule-generator.
>>>
>>>> I CHOSE not to use it and plan to not use it.  I PREFER eudev whether
>>>> you like
>>>> that decision or not.  I also plan to use eudev as long as it
>>>> serves my
>>>> needs as I suspect others will as well.  You can preach FUD all you
>>>> want
>>>> but it works here for me and as others have posted, it works fine for
>>>> them.  The OP asked for assistance in switching to eudev not for
>>>> you to
>>>> second guess their choice or to second guess anyone else who
>>>> chooses to
>>>> use it.
>>>
>>> I feel pity for you, too bad the eudev in tree causes such level of
>>> ignorance.
>>>
>>> - Samuli
>>>
>>>
>>
>>
>> Here is some FUD for you.  Eudev just left beta.  From the eudev
>> changelog.
>>
>> *eudev-1.2 (01 Aug 2013)
>>
>>    01 Aug 2013; Ian Stakenvicius <[hidden email]> +eudev-1.2.ebuild,
>>    -eudev-1.2_beta.ebuild:
>>    version bump, remove beta
>
> And how did they get there?
> By udev maintainers forcing them to upgrade to the new keymap hwdb
> which required version to be raised to up-to-par with udev-206.
>
> Anyway, have fun with pointless udev fork which will never be the
> default. I don't care if you don't want the system up-to-par with
> production level system. :-)
>
> - Samuli
>
>

They got there by fixing issues and it reaching stable.  That is how
they got there.  You don't know that and you are telling others what to
use for their system?  Really?  Who exactly do you think you are
anyway?  Did someone appoint you Gentoo King or something?  Here is
where we will always differ, I decide on my machine what I use, NOT
YOU.  If I don't like a piece of software and CHOSE to use something
else, you don't get a say in the matter.  Got it?  Eudev forked from
udev, get over it.

I'm not in the mood for someone shoving something down my throat.  That
goes for Lennart and you too.  I use eudev, and I plan to do so as long
as it serves my needs.  The only one spreading FUD here is you.

Since you are way off the mark of what the OP asked for, why not go
write a blog or something.  Maybe go write a blog for Lennart instead of
trying to push your agenda here.  The OP came here for help to switch to
eudev not to hear you shove your agenda.  He/she already made their
choice as have others.

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Alan McKinnon-2
On 02/08/2013 14:10, Dale wrote:
> Here is
> where we will always differ, I decide on my machine what I use, NOT
> YOU.



Hey Dale,

Tell us how you really feel. Don't hold back :-)


[[ hugz and peace ]]

--
Alan McKinnon
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Moving from old udev to eudev

Dale-46
In reply to this post by tanstaafl-2
Tanstaafl wrote:

> On 2013-08-01 5:41 PM, Dale <[hidden email]> wrote:
>> When the version of udev came out that was said to require a init thingy
>> or /usr on /, that is when I switched to eudev.  I haven't used the
>> newer versions of udev.   I do have this in my kernel config tho:
>>
>> root@fireball / # cat /usr/src/linux/.config | grep -i CONFIG_DEVTMPFS
>> CONFIG_DEVTMPFS=y
>> CONFIG_DEVTMPFS_MOUNT=y
>> root@fireball / #
>
> Thanks Dale... looks easy enough...
>
> But what about removing the udev-postmount init script? I guess that
> is the last question I need answered before jumping down the rabbit
> hole Sunday...
>
> Thanks again to all who responded...
>
>

This is what I have for that from rc-update show:

udev-postmount |      default

If you have something that says different, can you post a link?  I'd
like to see that.  I don't recall removing any script but again, I was a
early switcher.

Please excuse the agenda posts by Samuli.  If you chose eudev, like me
and plenty of others, use eudev.  It's your system and you know what you
need to use.

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


123456