[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] Moving from old udev to eudev
From:       Samuli Suominen <ssuominen () gentoo ! org>
Date:       2013-08-12 14:01:08
Message-ID: 5208EAA4.9020702 () gentoo ! org
[Download RAW message or body]

On 12/08/13 16:39, hasufell wrote:
> On 08/12/2013 02:06 PM, Samuli Suominen wrote:
>> On 12/08/13 14:37, hasufell wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 08/02/2013 05:01 AM, 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
>>>> udev-bugs@g.o 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
>>>>
>>>>
>>>
>>> * you are not telling the whole story about what happened and why the
>>> fork came into life in the first place. It's not as simple as you seem
>>
>> True, I didn't mention people were needlessly unwilling to join the
>> Gentoo udev team despite being invited to.
>
> That's a bit unrelated. It wasn't just about the gentoo ebuild.

That's all it was.

>>> to suggest. There were good reasons at that point. Some changes were
>>> merged by udev upstream and there are still more differences than you
>>> point out. That has been discussed numerous of times.
>>> * claiming that eudev didn't improve anything is wrong and can be proven
>>
>> I can easily prove eudev is nothing but udev and deleted code, plus
>> restored broken 'rule generator', plus useless kept static nodes
>> creation which was moved to kmod, plus needlessly changed code for
>> uclibc support -- uclibc now has the functions udev needs.
>>
>
> Wonder why udev upstream merged back changes if it was all that bad.

Merged back what changes? That'd be news to me. I think you might be 
confusing something.

>>> * that eudev is behind udev most of the time is correct
>>> * that it causes tons of breakage for users... well, I don't know, not
>>> for me since almost the beginning
>>> * eudev will not be treecleaned until the gentoo devs who maintain it
>>> agree (at best, it may be masked) and even if eudev will be obsolete
>>> at some point, then it has been a success
>>> * I don't understand why you add those rants all over different
>>> mailing lists. I have seen it numerous of times and your precision
>>> about explaining the situation does not improve. If you think that
>>> people need to be warned about eudev, then you should provide a reason
>>> to mask it or drop it back to ~arch. Anything else is not constructive
>>> and causes confusion.
>>
>> True, it won't be dropped for long as people are maintaining it. That's
>> how maintainership works.
>> But trying to lie to people it's somehow solving something currently is
>> annoying as 'ell and should be corrected where seen.
>>
>
> Who lied?

Let's rephrase lying with FUD for correctness.


[prev in list] [next in list] [prev in thread] [next in thread]