-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/02/16 07:46 AM, Michał Górny wrote: > On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer > <patr...@gentoo.org> wrote: > >> Ohey, >> >> I've opened a bug at: >> https://bugs.gentoo.org/show_bug.cgi?id=573922 >> >> The idea here is to change the order of the providers of >> virtual/udev. For existing installs this has zero impact. For >> stage3 this would mean that eudev is pulled in instead of >> udev. >> >> The rationale behind this is: >> >> * eudev is an in-house fork, and there's more than a dozen >> distros already using it by default that are not us. Which is a >> little bit weird ... > > That's not an argument. I can also fork random system components. > Would you consider that a reason to replace the defaults with our > 'in-house' forks? > >> * Both udev and eudev have pretty much feature parity, so there >> won't be any user-visible changes >> >> * udev upstream strongly discourages standalone udev (without >> systemd) since at least 2012 >> >> (see for example: >> https://lists.freedesktop.org/archives/systemd-devel/2012-June/0055 16.html >> >> https://lkml.org/lkml/2012/10/3/618 >> ) >> >> So it'd be (1) following upstreams recommendations and (2) >> dogfooding our own tools. I don't see any downsides to this :) > > I'm strongly against this, because: > > 1. It is a conflict-induced fork. As such, it will never be > merged upstream and it will never be supported upstream. In fact, > it is continually forces to follow upstream changes and adapt to > them. eudev is more likely to break because of the Gentoo > developer(s) working hard to merge upstream changes to their > incompatible code.
Yes this is true -- however, this claim is based on sys-fs/udev actually being an upstream package and it really isn't -- it's a partial package of systemd that upstream really doesn't support as a separate package anyhow (hence the size and complexity of the ebuild to build it). > > 2. Many of Gentoo users are programmers who appreciate the > 'vanilla' API experience Gentoo often provides. Switching the > defaults to a fork that is known to intentionally diverge from > upstream goes against that principle. Programs written against > eudev may not work correctly with upstream udev. No. Eudev ensures compatibility with systemd-udev as a principle, we are not going to fork the API. Unless upstream decides to do something with udev that breaks it previous API in an incompatible way that cannot be reproduced without the rest of systemd, eudev will retain API compatibility with systemd-udev. Eudev would not be nearly as useful as it is, if it wasn't a drop-in replacement for upstream udevd and libudev. Besides, now that gudev is its own package there's really just libudev (rarely changes now), rules.d syntax (afaik hasnt changed since before the fork), and the support for the builtin's (which we keep up with) that we need to maintain. > 3. eudev has fallen behind systemd/udev more than once in the > past, and caused visible breakage to users this way. Similarly, in the last 6-12 months eudev's releases have been AHEAD of sys-fs/udev more than once, too. > 4. eudev is underdocumented, and the maintainer admits that 'he > sucks at documenting'. In fact, did anyone even bother to note > how far eudev diverges from upstream udev to this point? At this point, WITHOUT the patch applied by USE="rule-generator", divergence is fairly minimal -- the primary difference is that udev and libudev contain the internal functions that have been migrated upstream into the giant libsystemd-common. Most of the various improvement patches that we made in the early days have either been integrated upstream or have been dropped as they are no longer relevant. Blueness knows more on this, as I haven't done a thorough examination of upstream's code in quite a while. Oh, eudev also doesn't handle network link setup given that external tools already do this just fine. That's another difference, though not one that matters programmatically. That said, the network-link setup was added primarily to support systemd's use-case, and there's very little need or point in having it done by udevd on an rc-based system. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAla4u48ACgkQAJxUfCtlWe02JgD+KjY9zpYjh8JZf1gAu3QUahjN EqtAkPbXZLsELPBuAHgA/Aq2sHQIFg2iKYKow29HXIb43JKUbV96t37m9tUIBBm4 =trQk -----END PGP SIGNATURE-----
