diff --git a/virtual/udev/udev-217.ebuild b/virtual/udev/udev-217.ebuild index 29041b3..d954035 100644 --- a/virtual/udev/udev-217.ebuild +++ b/virtual/udev/udev-217.ebuild @@ -15,5 +15,5 @@ IUSE="systemd" DEPEND="" RDEPEND=" - !systemd? ( || ( >=sys-fs/udev-217 >=sys-fs/eudev-2.1.1 ) ) + !systemd? ( || ( >=sys-fs/eudev-2.1.1 >=sys-fs/udev-217 ) ) systemd? ( >=sys-apps/systemd-217:0 )" This has the advantage that Gentoo would use the Gentoo-maintained version as default, which sounds pretty reasonable to me ...
In favour. eudev is the better option for non-systemd installations.
Against. People choose Gentoo because it follows upstream and can be relied on. Putting random forks by default is a bad idea since it hurts the expected uniformity.
(In reply to Michał Górny from comment #2) > Against. People choose Gentoo because it follows upstream and can be relied > on. Putting random forks by default is a bad idea since it hurts the > expected uniformity. What expectation? No one uses plain udev anymore, it's all systemd, and eudev is a well-maintained fork that every other gentoo derivative (e.g. funtoo) seems to use. That we don't dogfood our own products is sad :)
I'm a systemd guy, but if eudev is working for people I have no objection to making it the default. It would be nice to have some documented reason for it though. What makes eudev a better choice for non-systemd users?
(In reply to Mike Gilbert from comment #4) > I'm a systemd guy, but if eudev is working for people I have no objection to > making it the default. I am maintaining it for sure. It looks like I haven't done much lately but I had to freeze it until the kdbus stuff settles down then there will be a major rebasing, probably in a few months. > > It would be nice to have some documented reason for it though. What makes > eudev a better choice for non-systemd users? I suck at documenting. I was just pointing people to the udev documentation. If udev is going away, then we can merge that info over to the eudev page.
(In reply to Anthony Basile from comment #5) > I suck at documenting. I was just pointing people to the udev > documentation. If udev is going away, then we can merge that info over to > the eudev page. You misunderstand what I am asking. I would just like someone to state in this bug report some reasons why we should switch to eudev by default. That way we have something to point back to when random person X asks "why did you do this?"
(In reply to Mike Gilbert from comment #6) > (In reply to Anthony Basile from comment #5) > > I suck at documenting. I was just pointing people to the udev > > documentation. If udev is going away, then we can merge that info over to > > the eudev page. > > You misunderstand what I am asking. I would just like someone to state in > this bug report some reasons why we should switch to eudev by default. That > way we have something to point back to when random person X asks "why did > you do this?" https://forums.gentoo.org/viewtopic-t-1003230.html also, standalone udev is strongly deprecated upstream, and eudev is a supported in-house flavour, so I'd like some reasons why we should stick with the less supported version ...
(In reply to Michał Górny from comment #2) > Against. People choose Gentoo because it follows upstream and can be relied > on. Putting random forks by default is a bad idea since it hurts the > expected uniformity. And yet Gentoo decided to make the "fork" of ffmpeg, avlib, the default and look what happened ... so please don't hide behind some pseudo clause about "following upstream" when this isn't actually followed.
(In reply to jon R-B from comment #8) > (In reply to Michał Górny from comment #2) > > Against. People choose Gentoo because it follows upstream and can be relied > > on. Putting random forks by default is a bad idea since it hurts the > > expected uniformity. > > And yet Gentoo decided to make the "fork" of ffmpeg, avlib, the default and > look what happened ... so please don't hide behind some pseudo clause about > "following upstream" when this isn't actually followed. You are incorrect here and your unrelated comments are unwelcome.
(In reply to Michał Górny from comment #2) > Against. People choose Gentoo because it follows upstream and can be relied > on. Putting random forks by default is a bad idea since it hurts the > expected uniformity. Also against, because this bug really hasn't shown a technical reason to make the switch happen. (In reply to Patrick Lauer from comment #7) > also, standalone udev is strongly deprecated upstream, and eudev is a > supported in-house flavour, so I'd like some reasons why we should stick > with the less supported version ... Not true. Yes, they say it should be built with system, but there is no requirement that system has to be running to run it, and the build is fine without system the way we work it in the ebuild. I don't know how comparable eudev really is to udev, but I think it is reasonable to assume that it doesn't have all of udev's features since it is a fork and has to keep up. I would rather not make that switch and cause issues with the distro until udev forces the issue.
(In reply to Patrick Lauer from comment #3) > No one uses plain udev anymore Everyone uses plain udev, your assertion is misguided. It's the exact same _up to date_ code as every pure systemd distribution uses too. It just happens to be built together and then split into multiple binary packages (e.g libudev1 in Ubuntu - http://packages.ubuntu.com/source/wily/systemd), while we have the added burden of doing that at source level - but for various reasons systemd package also installs udev, hence only one of udev or systemd (or eudev IFF systemd is not used). The resulting binaries and supporting files are theoretically identical between sys-fs/udev with those coming out of sys-apps/systemd.
re-opening due to the discussion on the mailing list.
(In reply to Michał Górny from comment #9) > (In reply to jon R-B from comment #8) > > (In reply to Michał Górny from comment #2) > > > Against. People choose Gentoo because it follows upstream and can be relied > > > on. Putting random forks by default is a bad idea since it hurts the > > > expected uniformity. > > > > And yet Gentoo decided to make the "fork" of ffmpeg, avlib, the default and > > look what happened ... so please don't hide behind some pseudo clause about > > "following upstream" when this isn't actually followed. > > You are incorrect here and your unrelated comments are unwelcome. how so? Around february 2014 libav was set as the default audio-visual library in gentoo in a very aggressive way... not just in placing libav before ffmpeg but explicitly mislabeling a USE flag forcing a convoluted method to ensure ffmpeg was used. libav forked and hijacked the namespace of ffmpeg and actually exposed security issues and yet Gentoo facilitated this. Thus the stance "follows upstream" is moot. And why eudev over udev? 1) https://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.) 2) https://lists.freedesktop.org/archives/systemd-devel/2015-May/032147.html A new (currently still internal) API sd-device.h has been added to libsystemd. This modernized API is supposed to replace libudev eventually. In fact, already much of libudev is now just a wrapper around sd-device.h. last rites have been called on udev so much so that standalone udev may or may not have been given needed features since 2012 & equally a drive from within systemd has been to depreciate it with another device manager. The only thing that slowed this down was the monstrosity that was kdbus that clique tried to shoehorn into the kernel to then leverage off sd-bus
(In reply to Mart Raudsepp from comment #11) > Everyone uses plain udev, your assertion is misguided. 1. AUSTRUMI switched to eudev in March 2013 (see package list for the 2.6.8 release). 2. Parted Magic switched to eudev in August 2013. 3. Quirky (experimental version of Puppy Linux) switched to eudev in December 2013. 4. 0linux switched to eudev in February 2014 (see base packages for the eta release). 5. Linux From Scratch (standard version) switched to eudev in March 2014 (see this commit). 6. Vine Linux switched to eudev in June 2014. 7. Funtoo Linux switched to eudev in June 2014. 8. CRUX switched to eudev in July 2014. 9. Void Linux switched to eudev in July 2014 (see this commit). 10. Guix System Distribution switched to eudev in September 2014. 11. NuTyX switched to eudev in October 2014 (see system packages for the Saravane release). 12. Puppy Linux (standard version) switched to eudev in October 2014 (see package list for the 6.0 tahrpup release). 13. Manjaro Linux (OpenRC edition) has used eudev since the initial release in December 2014. 14. Calculate Linux switched to eudev in April 2015. 15. Alpine Linux (desktop edition) switched to eudev in July 2015.
(In reply to jon R-B from comment #13) > (In reply to Michał Górny from comment #9) > > (In reply to jon R-B from comment #8) > > > (In reply to Michał Górny from comment #2) > > > > Against. People choose Gentoo because it follows upstream and can be relied > > > > on. Putting random forks by default is a bad idea since it hurts the > > > > expected uniformity. > > > > > > And yet Gentoo decided to make the "fork" of ffmpeg, avlib, the default and > > > look what happened ... so please don't hide behind some pseudo clause about > > > "following upstream" when this isn't actually followed. > > > > You are incorrect here and your unrelated comments are unwelcome. > > how so? > Around february 2014 libav was set as the default audio-visual library in > gentoo in a very aggressive way... not just in placing libav before ffmpeg > but explicitly mislabeling a USE flag forcing a convoluted method to ensure > ffmpeg was used. > libav forked and hijacked the namespace of ffmpeg and actually exposed > security issues and yet Gentoo facilitated this. Thus the stance "follows > upstream" is moot. @comrel, please consider the case of Jon as repeatedly derailing the bug even though asked not to. @Jon, I suggest you look into actual proofs and explanations rather than blaming everyone for your misfortune. If you have doubts, you can talk about this *elsewhere* as this is not the bug.
(In reply to Greg Kubaryk from comment #14) > (In reply to Mart Raudsepp from comment #11) > > Everyone uses plain udev, your assertion is misguided. > > 1. AUSTRUMI switched to eudev in March 2013 (see package list for the 2.6.8 > release). > 2. Parted Magic switched to eudev in August 2013. > 3. Quirky (experimental version of Puppy Linux) switched to eudev in > December 2013. > 4. 0linux switched to eudev in February 2014 (see base packages for the eta > release). > 5. Linux From Scratch (standard version) switched to eudev in March 2014 > (see this commit). > 6. Vine Linux switched to eudev in June 2014. > 7. Funtoo Linux switched to eudev in June 2014. > 8. CRUX switched to eudev in July 2014. > 9. Void Linux switched to eudev in July 2014 (see this commit). > 10. Guix System Distribution switched to eudev in September 2014. > 11. NuTyX switched to eudev in October 2014 (see system packages for the > Saravane release). > 12. Puppy Linux (standard version) switched to eudev in October 2014 (see > package list for the 6.0 tahrpup release). > 13. Manjaro Linux (OpenRC edition) has used eudev since the initial release > in December 2014. > 14. Calculate Linux switched to eudev in April 2015. > 15. Alpine Linux (desktop edition) switched to eudev in July 2015. Do you want me to start listing distributions that have switched to systemd? Or those who provide systemd-built udev as separate package with no dependency on systemd? Listing random forks of forks makes every list longer, you know.
(In reply to Michał Górny from comment #16) > > Do you want me to start listing distributions that have switched to systemd? that's an incorrect argument. we're not comparing systemd to eudev, but sys-fs/udev to sys-fs/eudev.
(In reply to Michał Górny from comment #16) > (In reply to Greg Kubaryk from comment #14) > > (In reply to Mart Raudsepp from comment #11) > > > Everyone uses plain udev, your assertion is misguided. > > > > 1. AUSTRUMI switched to eudev in March 2013 (see package list for the 2.6.8 > > release). > > 2. Parted Magic switched to eudev in August 2013. > > 3. Quirky (experimental version of Puppy Linux) switched to eudev in > > December 2013. > > 4. 0linux switched to eudev in February 2014 (see base packages for the eta > > release). > > 5. Linux From Scratch (standard version) switched to eudev in March 2014 > > (see this commit). > > 6. Vine Linux switched to eudev in June 2014. > > 7. Funtoo Linux switched to eudev in June 2014. > > 8. CRUX switched to eudev in July 2014. > > 9. Void Linux switched to eudev in July 2014 (see this commit). > > 10. Guix System Distribution switched to eudev in September 2014. > > 11. NuTyX switched to eudev in October 2014 (see system packages for the > > Saravane release). > > 12. Puppy Linux (standard version) switched to eudev in October 2014 (see > > package list for the 6.0 tahrpup release). > > 13. Manjaro Linux (OpenRC edition) has used eudev since the initial release > > in December 2014. > > 14. Calculate Linux switched to eudev in April 2015. > > 15. Alpine Linux (desktop edition) switched to eudev in July 2015. > > Do you want me to start listing distributions that have switched to systemd? > Or those who provide systemd-built udev as separate package with no > dependency on systemd? Listing random forks of forks makes every list > longer, you know. The statement was *everyone* uses udev. It only took the proof of one to refute that statement
(In reply to Michał Górny from comment #15) > (In reply to jon R-B from comment #13) > > (In reply to Michał Górny from comment #9) > > > (In reply to jon R-B from comment #8) > > > > (In reply to Michał Górny from comment #2) > > > > > Against. People choose Gentoo because it follows upstream and can be relied > > > > > on. Putting random forks by default is a bad idea since it hurts the > > > > > expected uniformity. > > > > > > > > And yet Gentoo decided to make the "fork" of ffmpeg, avlib, the default and > > > > look what happened ... so please don't hide behind some pseudo clause about > > > > "following upstream" when this isn't actually followed. > > > > > > You are incorrect here and your unrelated comments are unwelcome. > > > > how so? > > Around february 2014 libav was set as the default audio-visual library in > > gentoo in a very aggressive way... not just in placing libav before ffmpeg > > but explicitly mislabeling a USE flag forcing a convoluted method to ensure > > ffmpeg was used. > > libav forked and hijacked the namespace of ffmpeg and actually exposed > > security issues and yet Gentoo facilitated this. Thus the stance "follows > > upstream" is moot. > > @comrel, please consider the case of Jon as repeatedly derailing the bug > even though asked not to. > > @Jon, I suggest you look into actual proofs and explanations rather than > blaming everyone for your misfortune. If you have doubts, you can talk about > this *elsewhere* as this is not the bug. The statement was Gentoo follows upstream as to why udev should stay the default. The ffmpeg example was used to refute this. But sure cherrypick my reply and report. This should be interesting
Sounds legit to me. eudev is a device manager. I have not yet found a device it can not handle. So from here, it does not look like systemd-udev can provide any mission critical features eudev doesn't provide. Because that would mean I'd stumble over a device my device-manager (eudev) can't handle. However, there are these two things I'd like to add: 1) It is irrelevant how many examples for the validity of a theory you provide. It only needs one counterexample to prove that a theory is wrong. This means that both theories mentioned in this bug, a) "Everybody uses plain udev" and b) "Gentoo follows upstream" have been proven wrong. They are off the table. 2) It is widely known that the systemd devs want to make udev without a running systemd to disappear. No, I will not go digging up a few dozen links. Everybody who doesn't live under a rock knows this and that it's just political squabbling towards systemd world domination. It doesn't matter when it will happen. It will. Be it in 2030 if you like. It's irrelevant. Eventually there is only limited technical argument possible. The only relevant issue is with the ebuild maintaining. Which one is easier? Which one will, with coming new versions, break user systems less likely without interference by the user? Which one will more likely get a user, although far fetched, into dependency problems or blockers? Patricks change just switches an ordering. Eventually it is the user who decides what to run. And that choice doesn't look to me like it is in any danger of disappearing...
(In reply to William Hubbs from comment #12) > re-opening due to the discussion on the mailing list. William, as a fellow developer, ComRel member and former Council member, I'd like to point that imposing a decision about a virtual as a member of one of the "competing" providers' team is not OK. By "imposing" I mean having closed it as WONTFIX. Thank you for reopening the bug. I'm marking this bug as CONFIRMED as the discussion has been raised and this is a valid bug regardless of how we end up "resolving it".
(In reply to Patrick Lauer from comment #0) > diff --git a/virtual/udev/udev-217.ebuild b/virtual/udev/udev-217.ebuild > index 29041b3..d954035 100644 > --- a/virtual/udev/udev-217.ebuild > +++ b/virtual/udev/udev-217.ebuild > @@ -15,5 +15,5 @@ IUSE="systemd" > > DEPEND="" > RDEPEND=" > - !systemd? ( || ( >=sys-fs/udev-217 >=sys-fs/eudev-2.1.1 ) ) > + !systemd? ( || ( >=sys-fs/eudev-2.1.1 >=sys-fs/udev-217 ) ) > systemd? ( >=sys-apps/systemd-217:0 )" > > > This has the advantage that Gentoo would use the Gentoo-maintained version > as default, which sounds pretty reasonable to me ... I agree with this proposal and have always argued this is the correct way to get eudev in our stages - instead of comrel creating it's own profile to force it.
(In reply to Jorge Manuel B. S. Vicetto from comment #22) > I agree with this proposal and have always argued this is the correct way to > get eudev in our stages - instead of comrel creating it's own profile to > force it. Apologies for the noise, but to leave no doubts, I meant "releng" and not "comrel" above. There's no ComRel hat wavering going on.
How many distros have: 1) systemd is not their default init 2) use systemd's udev as their default /dev manager ? Everyone keeps bringing up systemd in regards to this but that is not relevant at all. the RDEPEND clearly states: systemd? ( >=sys-apps/systemd-217:0 ). (In reply to Michał Górny from comment #16) > Do you want me to start listing distributions that have switched to systemd? not relevant at all to this discussion. > Or those who provide systemd-built udev as separate package with no > dependency on systemd? yes, that is very relevant here. I am curious and such a list would help me make a decision. Patrick claims it is unsupported and has given proof. I have seen no proof from anyone that wishes to keep the default that it is supported.
I said "everyone uses plain udev" in the context of Patricks message; I didn't mean that actually everyone uses it, but that almost everyone percentage-wise does. This is fact unless those 15 fringe distros listed above somehow come anywhere near close to the usage of Fedora, Debian, Ubuntu, Mageia, Mint, RHEL, Arch Linux and so on and on. (In reply to Jason Zaman from comment #24) > How many distros have: > 1) systemd is not their default init > 2) use systemd's udev as their default /dev manager > ? > > Everyone keeps bringing up systemd in regards to this but that is not > relevant at all. the RDEPEND clearly states: systemd? ( > >=sys-apps/systemd-217:0 ). This is highly relevant, as we are talking about the code coming out of systemd tarball as being what is built by sys-fs/udev package. That being the code that almost every other relevant Linux distribution uses for udev. They just have the luxury of building both systemd and udev packages out of systemd in one go and then splitting it up post-build into multiple binary packages. We don't have such luxury, so we have a somewhat hacky sys-fs/udev unfortunately indeed, to do it at source level (and it's too manpower consuming to make sys-apps/systemd use that sys-fs/udev due to some common internal library usages iirc and many other reasons). You can consider sys-fs/udev the equivalent of e.g Ubuntu's libudev1 package, to make it more understandable. > (In reply to Michał Górny from comment #16) > > Do you want me to start listing distributions that have switched to systemd? > not relevant at all to this discussion. Same as above. > > Or those who provide systemd-built udev as separate package with no > > dependency on systemd? > yes, that is very relevant here. I am curious and such a list would help me > make a decision. Patrick claims it is unsupported and has given proof. I > have seen no proof from anyone that wishes to keep the default that it is > supported. As above, other major distributions libudev1 packages are built from the same source as our sys-fs/udev is.
(In reply to Mart Raudsepp from comment #25) > I said "everyone uses plain udev" in the context of Patricks message; I > didn't mean that actually everyone uses it, but that almost everyone > percentage-wise does. This is fact unless those 15 fringe distros listed > above somehow come anywhere near close to the usage of Fedora, Debian, > Ubuntu, Mageia, Mint, RHEL, Arch Linux and so on and on. ha ha ha ha.... these are using udev in the context of systemd, so maybe we kill OpenRC eco-system and force switch to systemd? please try to understand eudev is the upstream for udev for OpenRC eco-system, these that insist to use the systemd udev can if they like, however, to preserve the freedom to use non systemd systems in future we would like to also suggest eudev, which is better than systemd to force one implementation of udev.
I'd like to ask everyone to move the discussion out of this bug and into the dev ml to reduce the noise here.
Per the linked bug, the council has decided: "In light of the support for eudev among Gentoo non-systemd users, and a lack of strong technical drivers to block a change, the Council approves changing the default virtual/udev provider for non-systemd users to eudev. The council encourages all maintainers to try to support either provider and cooperate with those who provide patches when necessary." I'd recommend that the eudev team implement and communicate the change. If they are willing I'd like to co-announce planned support for systemd-stage3 autobuilds to try to further the point that this is about offering our users the configurations they prefer.
Change has been committed.
