| 1 |
On 02/08/13 06:14, Dale wrote: |
| 2 |
> Samuli Suominen wrote: |
| 3 |
>> On 02/08/13 05:48, Dale wrote: |
| 4 |
>>> Samuli Suominen wrote: |
| 5 |
>>>> |
| 6 |
>>>> Huh? USE="firmware-loader" is optional and enabled by default in |
| 7 |
>>>> sys-fs/udev |
| 8 |
>>>> Futhermore predictable network interface names work as designed, not a |
| 9 |
>>>> single valid bug filed about them. |
| 10 |
>>>> |
| 11 |
>>>> Stop spreading FUD. |
| 12 |
>>>> |
| 13 |
>>>> Looking forward to lastrite sys-fs/eudev just like |
| 14 |
>>>> sys-apps/module-init-tools already was removed as unnecessary later on. |
| 15 |
>>> |
| 16 |
>>> So your real agenda is to kill eudev? Maybe it is you that is spreading |
| 17 |
>>> FUD instead of others. Like others have said, udev was going to cause |
| 18 |
>>> issues, eudev has yet to cause any. |
| 19 |
>> |
| 20 |
>> Yes, absolutely sys-fs/eudev should be punted from tree since it |
| 21 |
>> doesn't bring in anything useful, and it reintroduced old bugs from |
| 22 |
>> old version of udev, as well as adds confusing to users. |
| 23 |
>> And no, sys-fs/udev doesn't have issues, in fact, less than what |
| 24 |
>> sys-fs/eudev has. |
| 25 |
>> Like said earlier, the bugs assigned to udev-bugs@g.o apply also to |
| 26 |
>> sys-fs/eudev and they have even more in their github ticketing system. |
| 27 |
>> And sys-fs/udev maintainers have to constantly monitor sys-fs/eudev so |
| 28 |
>> it doesn't fall too much behind, which adds double work unnecessarily. |
| 29 |
>> They don't keep it up-to-date on their own without prodding. |
| 30 |
>> |
| 31 |
>> Really, this is how it has went right from the start and the double |
| 32 |
>> work and user confusion needs to stop. |
| 33 |
>> |
| 34 |
>> - Samuli |
| 35 |
>> |
| 36 |
>> |
| 37 |
> |
| 38 |
> So any bug that udev has eudev has too? |
| 39 |
|
| 40 |
Yes, because eudev is copying the upstream code over from udev. |
| 41 |
|
| 42 |
> Then with that logic, udev is just as unstable as eudev. |
| 43 |
|
| 44 |
Except it isn't because as already explained, eudev makes additional |
| 45 |
changes on top of udev changes. |
| 46 |
|
| 47 |
> You claim eudev has a bug that udev doesn't, |
| 48 |
|
| 49 |
Which is true. |
| 50 |
|
| 51 |
> let's see them. Based on your posts, there should be plenty of them. |
| 52 |
> Funny I haven't ran into any of them yet tho. |
| 53 |
|
| 54 |
I'm not suprised, because the current status is so similar between udev |
| 55 |
vs. eudev. Only regression that's known currently is |
| 56 |
IUSE="+rule-generator" that doesn't do it's job correctly and |
| 57 |
70-persistent-net.rules it is generating can't be trusted. |
| 58 |
|
| 59 |
> Here is the deal OK. Udev went in a direction I do NOT like. |
| 60 |
|
| 61 |
What direction is that? Everything same is in sys-fs/udev than is in |
| 62 |
sys-fs/eudev, except the buggy rule-generator. |
| 63 |
|
| 64 |
> I CHOSE not to use it and plan to not use it. I PREFER eudev whether you like |
| 65 |
> that decision or not. I also plan to use eudev as long as it serves my |
| 66 |
> needs as I suspect others will as well. You can preach FUD all you want |
| 67 |
> but it works here for me and as others have posted, it works fine for |
| 68 |
> them. The OP asked for assistance in switching to eudev not for you to |
| 69 |
> second guess their choice or to second guess anyone else who chooses to |
| 70 |
> use it. |
| 71 |
|
| 72 |
I feel pity for you, too bad the eudev in tree causes such level of |
| 73 |
ignorance. |
| 74 |
|
| 75 |
- Samuli |
Archives