On 02/08/13 09:06, Alon Bar-Lev wrote:
On Fri, Aug 2, 2013 at 6:17 AM, William Kenworthy <bi...@iinet.net.au> 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 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
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.
