Gentoo Archives: gentoo-user

From: Samuli Suominen <ssuominen@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Moving from old udev to eudev
Date: Mon, 12 Aug 2013 14:03:41
Message-Id: 5208EAA4.9020702@gentoo.org
In Reply to: Re: [gentoo-user] Moving from old udev to eudev by hasufell
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.