1 |
On 12/08/13 16:39, hasufell wrote: |
2 |
> On 08/12/2013 02:06 PM, Samuli Suominen wrote: |
3 |
>> On 12/08/13 14:37, hasufell wrote: |
4 |
>>> -----BEGIN PGP SIGNED MESSAGE----- |
5 |
>>> Hash: SHA1 |
6 |
>>> |
7 |
>>> On 08/02/2013 05:01 AM, Samuli Suominen wrote: |
8 |
>>>> On 02/08/13 05:48, Dale wrote: |
9 |
>>>>> Samuli Suominen wrote: |
10 |
>>>>>> |
11 |
>>>>>> Huh? USE="firmware-loader" is optional and enabled by default |
12 |
>>>>>> in sys-fs/udev Futhermore predictable network interface names |
13 |
>>>>>> work as designed, not a single valid bug filed about them. |
14 |
>>>>>> |
15 |
>>>>>> Stop spreading FUD. |
16 |
>>>>>> |
17 |
>>>>>> Looking forward to lastrite sys-fs/eudev just like |
18 |
>>>>>> sys-apps/module-init-tools already was removed as unnecessary |
19 |
>>>>>> later on. |
20 |
>>>>> |
21 |
>>>>> So your real agenda is to kill eudev? Maybe it is you that is |
22 |
>>>>> spreading FUD instead of others. Like others have said, udev was |
23 |
>>>>> going to cause issues, eudev has yet to cause any. |
24 |
>>>> |
25 |
>>>> Yes, absolutely sys-fs/eudev should be punted from tree since it |
26 |
>>>> doesn't bring in anything useful, and it reintroduced old bugs from |
27 |
>>>> old version of udev, as well as adds confusing to users. And no, |
28 |
>>>> sys-fs/udev doesn't have issues, in fact, less than what |
29 |
>>>> sys-fs/eudev has. Like said earlier, the bugs assigned to |
30 |
>>>> udev-bugs@g.o apply also to sys-fs/eudev and they have even more in |
31 |
>>>> their github ticketing system. And sys-fs/udev maintainers have to |
32 |
>>>> constantly monitor sys-fs/eudev so it doesn't fall too much behind, |
33 |
>>>> which adds double work unnecessarily. They don't keep it up-to-date |
34 |
>>>> on their own without prodding. |
35 |
>>>> |
36 |
>>>> Really, this is how it has went right from the start and the double |
37 |
>>>> work and user confusion needs to stop. |
38 |
>>>> |
39 |
>>>> - Samuli |
40 |
>>>> |
41 |
>>>> |
42 |
>>> |
43 |
>>> * you are not telling the whole story about what happened and why the |
44 |
>>> fork came into life in the first place. It's not as simple as you seem |
45 |
>> |
46 |
>> True, I didn't mention people were needlessly unwilling to join the |
47 |
>> Gentoo udev team despite being invited to. |
48 |
> |
49 |
> That's a bit unrelated. It wasn't just about the gentoo ebuild. |
50 |
|
51 |
That's all it was. |
52 |
|
53 |
>>> to suggest. There were good reasons at that point. Some changes were |
54 |
>>> merged by udev upstream and there are still more differences than you |
55 |
>>> point out. That has been discussed numerous of times. |
56 |
>>> * claiming that eudev didn't improve anything is wrong and can be proven |
57 |
>> |
58 |
>> I can easily prove eudev is nothing but udev and deleted code, plus |
59 |
>> restored broken 'rule generator', plus useless kept static nodes |
60 |
>> creation which was moved to kmod, plus needlessly changed code for |
61 |
>> uclibc support -- uclibc now has the functions udev needs. |
62 |
>> |
63 |
> |
64 |
> Wonder why udev upstream merged back changes if it was all that bad. |
65 |
|
66 |
Merged back what changes? That'd be news to me. I think you might be |
67 |
confusing something. |
68 |
|
69 |
>>> * that eudev is behind udev most of the time is correct |
70 |
>>> * that it causes tons of breakage for users... well, I don't know, not |
71 |
>>> for me since almost the beginning |
72 |
>>> * eudev will not be treecleaned until the gentoo devs who maintain it |
73 |
>>> agree (at best, it may be masked) and even if eudev will be obsolete |
74 |
>>> at some point, then it has been a success |
75 |
>>> * I don't understand why you add those rants all over different |
76 |
>>> mailing lists. I have seen it numerous of times and your precision |
77 |
>>> about explaining the situation does not improve. If you think that |
78 |
>>> people need to be warned about eudev, then you should provide a reason |
79 |
>>> to mask it or drop it back to ~arch. Anything else is not constructive |
80 |
>>> and causes confusion. |
81 |
>> |
82 |
>> True, it won't be dropped for long as people are maintaining it. That's |
83 |
>> how maintainership works. |
84 |
>> But trying to lie to people it's somehow solving something currently is |
85 |
>> annoying as 'ell and should be corrected where seen. |
86 |
>> |
87 |
> |
88 |
> Who lied? |
89 |
|
90 |
Let's rephrase lying with FUD for correctness. |