On Fri, Aug 2, 2013 at 10:03 AM, Samuli Suominen <ssuomi...@gentoo.org> wrote: > 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. >
No FUD... it can be currently with some patches, this is against agenda of upstream... but you are right it *CAN* be done... with effort and modifications. In future, even that "support" may be removed because of upstream agenda. I appreciate the effort of creating standalone udev project, I do not care if this is udev fork or mdev or anything else that provide userspace device management, that is free of commercial agenda and the dependency lock-in. As long as there is alternative to systemd upstream I will endorse it and use it to help the relevant upstream to improve his software. Regards, Alon
