Ok, trying not to start a derailed thread, but just saw the eselect news regarding the impending removal of eudev from gentoo on 2022-01-01
2021-08-24-eudev-retirement
Any ideas on how those of us which mask udev should proceed? I know just enough to get myself in trouble. I can just manage to point to overlays correctly.
Is moving eudev to an overlay somewhere a reasonable solution?
Regards,
Mark
eudev impending removal
Message
I don't think just keeping the latest ebuild around in an overlay is feasible. Udev is still under development and ongoing maintenance burden seems to be the very reason eudev is dropped.
If you're not dependent on virtual/udev specifically and virtual/dev-manager is enough I'd suggest giving busybox's mdev a try. I use it on some less complicated setups and so far it has done its job well over the years. Or you could even run an entirely static /dev like many here, but I wouldn't know about that.
Edit: https://wiki.gentoo.org/wiki/Mdev
If you're not dependent on virtual/udev specifically and virtual/dev-manager is enough I'd suggest giving busybox's mdev a try. I use it on some less complicated setups and so far it has done its job well over the years. Or you could even run an entirely static /dev like many here, but I wouldn't know about that.
Edit: https://wiki.gentoo.org/wiki/Mdev
- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
gtwrek,
Go with udev.
eudev will not be maintained an its a lot of work to keep it tracking systemd-udev.
I don't think that staying with an old eudev is an option.
There is also mdev which is doable. Others here have done it and can explain the nuances.
You could also go really hard core old school and not have any dynamic device management on your install at all.
That's what I did. It does need modified ebuilds so that things still build.
The original draft of the news item contained
Go with udev.
eudev will not be maintained an its a lot of work to keep it tracking systemd-udev.
I don't think that staying with an old eudev is an option.
There is also mdev which is doable. Others here have done it and can explain the nuances.
You could also go really hard core old school and not have any dynamic device management on your install at all.
That's what I did. It does need modified ebuilds so that things still build.
The original draft of the news item contained
blueness wrote: Rationale
The integration of udev into the systemd git repo introduced numerous
problems for none-glibc systems, such as musl and uclibc. Several
options were considered, and the one chosen was to fork and maintain
udev independant of the rest of systemd. This was meant as a stop-gap
solution until such time as the problems with systemd on musl had been
resolved. This is now the case with patches provided by openembedded,
and my original reason for maintaining eudev is no longer relevant.
I am willing to transfer eudev to another umbrella organisation or Linux
distribution that is willing to continue its maintenance, but
maintaining eudev cannot be done purely through proxy-maintaining and
requires an understanding of its internals. This is a steep learning
curve and must be an earnest effort. For this reason, the Base System
project has decided not to support euev as an option going forward.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Ok, reading the eselect news closer, I *think* I'm ok. My package.mask contains:
sys-apps/systemd
However, I don't use an INSTALL_MASK 'with a blanket "*systemd*" glob' so I should be ok.
On 2021-10-01, eudev will be masked, and portage will then pick up the udev components as necessary (following my package.mask) - using udev instead of eudev. Is this a correct assessment?
Thanks,
Mark
sys-apps/systemd
However, I don't use an INSTALL_MASK 'with a blanket "*systemd*" glob' so I should be ok.
On 2021-10-01, eudev will be masked, and portage will then pick up the udev components as necessary (following my package.mask) - using udev instead of eudev. Is this a correct assessment?
Thanks,
Mark
- eccerr0r
- Watchman
- Posts: 10239
- Joined: Thu Jul 01, 2004 6:51 pm
- Location: almost Mile High in the USA
- Contact:
opentmpfiles got masked (use systemd-tmpfiles)
eudev got masked (use systemd-udev)
elogind ...
(was looking for a smiley under a chair but looks like we don't have one here... but yes this hopefully will just remain a joke.)
eudev got masked (use systemd-udev)
elogind ...
(was looking for a smiley under a chair but looks like we don't have one here... but yes this hopefully will just remain a joke.)
Intel Core i7 2700K/Radeon Firepro W2100/24GB DDR3/800GB SSD
What am I supposed watching?
What am I supposed watching?
difference is, elogind isn't a Gentoo project so it should only be removed if it is no longer supported upstreameccerr0r wrote:opentmpfiles got masked (use systemd-tmpfiles)
eudev got masked (use systemd-udev)
elogind ...
(was looking for a smiley under a chair but looks like we don't have one here... but yes this hopefully will just remain a joke.)
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;
fwiw blueness (i.e. the last gentoo dev who was occasionally still working on eudev) reached out to other distros that use eudev to give them access to the eudev repo, but believe no one has stepped up so far (they may possibly go the same route and use standalone systemd udev). This ended up becoming a one-man project with no one really helping, and the primary reason was still maintaining this for (musl) isn't an issue anymore.Naib wrote:difference is, elogind isn't a Gentoo project so it should only be removed if it is no longer supported upstream
Edit: And this isn't exactly a project you can ignore and will "work forever". Need to keep up with devices rules, deps/kernel changes, and ensure libudev stays up to date (software will be keeping up with systemd's version, may use new features, and so on). So I'd generally advice against copying eudev to a local repo for those doing it, this is just issues waiting to happen.
For those that do use aggressive masks, a "-/lib/systemd/systemd-udevd" to INSTALL_MASK should be enough to selectively override other masks. It's only a symlink that udevadm uses to recognize that (when it contains *udevd) should start as a daemon -- and if missing, openrc won't know how to start udevd.gtwrek wrote:However, I don't use an INSTALL_MASK 'with a blanket "*systemd*" glob' so I should be ok.
It should have been possible to use /sbin/udevd without code changes instead but the original name still helps ensure it won't randomly break in some update. May have been worth using to make the transition safer, but there is also arguments people shouldn't be stripping whole *name* or system directory structures using INSTALL_MASK (instead of say.. /path/to/exact_file, or at most /path/to/*.service, or better yet -- ignoring small files) as it has far reaching implications.
Last edited by Ionen on Fri Aug 27, 2021 2:29 pm, edited 1 time in total.
I get the rationale for dropping the hard fork, but after reading the sys-fs/udev ebuild, I can't help but wonder if eudev wouldn't be better off becoming a build harness to more easily build udev without systemd, as well as pre-applying the openembedded patches, and whatever other goodies non-systemd users might need, without being a full hard-fork like eudev was. This is essentially a similar amount of effort as it takes to maintain an ebuild like sys-fs/udev as well as the openembedded patches, and would benefit other distributions as well as provide a single upstream to track the necessary build options/features/additional scripts/patches/configs/etc without having every distribution haphazardly copy each other's build scripts and create minor differences between eachother.
Essentially, what I'm proposing is what the icedtea project has been doing for aeons, and is comparable to perl-cross, wine-staging, or android-tools
Also I'm slightly disappointed to see USE=rule-generator go, as it was a nice in-between of keeping the old interface naming scheme as well as making them persistent across reboots.
Essentially, what I'm proposing is what the icedtea project has been doing for aeons, and is comparable to perl-cross, wine-staging, or android-tools
Also I'm slightly disappointed to see USE=rule-generator go, as it was a nice in-between of keeping the old interface naming scheme as well as making them persistent across reboots.
I don't see the problem here.
If udev (the systemd one) can be used without systemd, then why not to switch to it?
Same thing goes with tmpfiles -implementation.
Why to waste resources to develop software with identical functionality and goals? One might as well clone the systemd-udevd repo, rename it to ngudev (for example) and call it a day.
If a day comes when these software packages cannot work without systemd, there will be a forks. Trust me.
So... What am I missing here?
If udev (the systemd one) can be used without systemd, then why not to switch to it?
Same thing goes with tmpfiles -implementation.
Why to waste resources to develop software with identical functionality and goals? One might as well clone the systemd-udevd repo, rename it to ngudev (for example) and call it a day.
If a day comes when these software packages cannot work without systemd, there will be a forks. Trust me.
So... What am I missing here?
..: Zucca :..
Code: Select all
0100100100100000011000010110110100100000
0100111001100001010011100010000100100000
0100100100100000011000010110110100100000
0110000100100000011011010110000101101110
00100001It's already developed. The only ebuild maintenance needed is EAPI/python upgrades, which are self-imposed by Gentoo.Zucca wrote:Why to waste resources to develop software with identical functionality and goals? One might as well clone the systemd-udevd repo, rename it to ngudev (for example) and call it a day.
...
So... What am I missing here?
The real work would be to remove those future systemd tentacles from that big largely undocumented code base.
You know it will never be done. Instead, Gentoo will join Debian and so many others as a pure systemd distro.
That's the big deal.
If things get bad enough, there are enough people to handle forks or replacements.
There are non-systemd distros out there. And using those distros there are people who are willing to make contributions to those forks or replacements. Non-systemd gentoo users aren't here alone. ;)
There are non-systemd distros out there. And using those distros there are people who are willing to make contributions to those forks or replacements. Non-systemd gentoo users aren't here alone. ;)
..: Zucca :..
Code: Select all
0100100100100000011000010110110100100000
0100111001100001010011100010000100100000
0100100100100000011000010110110100100000
0110000100100000011011010110000101101110
00100001ebuild maintenance may be minor, but as Ionen noted above, that's not the real problem. The problem is that if Gentoo enacts an indefinite freeze at the version of udev (or eudev) that is current today, it will slowly become less compatible as other projects make changes that require the then-current udev.Tony0945 wrote:It's already developed. The only ebuild maintenance needed is EAPI/python upgrades, which are self-imposed by Gentoo.Zucca wrote:So... What am I missing here?
Maybe a vendor releases a device that needs a udev quirk entry to work around non-compliant behavior. Upstream udev adds that quirk. Does Gentoo pull in that quirk, or declare that hardware unsupported on Gentoo? What if that quirk relies on a configuration directive that was added in a udev release that Gentoo does not use, due to the freeze?
Maybe a popular project, like GNOME, finds yet another way to depend on low level details, and so ceases to work with "old" udev. Does Gentoo fork GNOME to remove that dependency? Patch the old udev to supply that detail? Take a major upgrade to the then-current udev to get the detail from upstream?
Yes, these are hypotheticals, but they or similar situations have happened before.
The systemd-fication of gentoo-linux is (once again) gaining momentum...Tony0945 wrote:It's already developed. The only ebuild maintenance needed is EAPI/python upgrades, which are self-imposed by Gentoo.Zucca wrote:Why to waste resources to develop software with identical functionality and goals? One might as well clone the systemd-udevd repo, rename it to ngudev (for example) and call it a day.
...
So... What am I missing here?
The real work would be to remove those future systemd tentacles from that big largely undocumented code base.
You know it will never be done. Instead, Gentoo will join Debian and so many others as a pure systemd distro.
That's the big deal.
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org
-- NeddySeagoon@forums.gentoo.org
As an OpenRC user I'm quite puzzled...
I'm happy to use some of the components of the systemd project that I need to get my system running smoothly without systemd.
Am I a blind sheep stepping into a trap for using such software from systemd? You decide.
I'm happy to use some of the components of the systemd project that I need to get my system running smoothly without systemd.
Am I a blind sheep stepping into a trap for using such software from systemd? You decide.
..: Zucca :..
Code: Select all
0100100100100000011000010110110100100000
0100111001100001010011100010000100100000
0100100100100000011000010110110100100000
0110000100100000011011010110000101101110
00100001- NeddySeagoon
- Administrator
- Posts: 56107
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
As eudev existed this didn't happen.
kdbus and busone seemed to have gone away and the threat appears to have receded ... for now.
However, Red Hat still need a kernel wrapper as a part of their Windowification of Linux, so the reprieve is, in my opinion, only temporary.
Static /dev still works for me, so that's my systemd/udev/eudev avoidance path.
kdbus and busone seemed to have gone away and the threat appears to have receded ... for now.
However, Red Hat still need a kernel wrapper as a part of their Windowification of Linux, so the reprieve is, in my opinion, only temporary.
Static /dev still works for me, so that's my systemd/udev/eudev avoidance path.
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Exactly. And if things go "the systemd way" we have many ways out. So the sheep can still escape. ;)Gatsby wrote:Time will tell.Zucca wrote:Am I a blind sheep stepping into a trap for using such software from systemd?
No need to fear systemd.
..: Zucca :..
Code: Select all
0100100100100000011000010110110100100000
0100111001100001010011100010000100100000
0100100100100000011000010110110100100000
0110000100100000011011010110000101101110
00100001If things go the full systemd way, the only way "out" will be straight to the slaughtering block.Zucca wrote:And if things go "the systemd way" we have many ways out.
You should better beware of it, otherwise you will end like the Trojans after they pulled the Greek gift (Trojan horse) into their fortifications.Zucca wrote:No need to fear systemd.
"Its your Gentoo, your way. When it breaks, you can keep all the pieces."
-- NeddySeagoon@forums.gentoo.org
-- NeddySeagoon@forums.gentoo.org
Discussion reminder, particularly involving systemd:
Historical patterns strongly indicate that as comments trend farther from constructive, chances significantly increase that the opportunity for discussion ends.
Based on the lack of code or links thereto, I'm not aware of anyone exchanging their pitchfork and torch for a shovel and a pick.
Historical patterns strongly indicate that as comments trend farther from constructive, chances significantly increase that the opportunity for discussion ends.
People have different opinions and not everyone agrees with the current path.Zucca wrote:What am I missing here?
Based on the lack of code or links thereto, I'm not aware of anyone exchanging their pitchfork and torch for a shovel and a pick.
Quis separabit? Quo animo?
Is there a recommended way to return a system to "normal" after unsetting INSTALL_MASK?Ionen wrote:For those that do use aggressive masks, a "-/lib/systemd/systemd-udevd" to INSTALL_MASK should be enough to selectively override other masks. It's only a symlink that udevadm uses to recognize that (when it contains *udevd) should start as a daemon -- and if missing, openrc won't know how to start udevd.
It should have been possible to use /sbin/udevd without code changes instead but the original name still helps ensure it won't randomly break in some update. May have been worth using to make the transition safer, but there is also arguments people shouldn't be stripping whole *name* or system directory structures using INSTALL_MASK (instead of say.. /path/to/exact_file, or at most /path/to/*.service, or better yet -- ignoring small files) as it has far reaching implications.
Although it turns out I'm not using eudev on that system, I'm trying to reduce as much unnecessary friction as possible. It is currently set with INSTALL_MASK=" /usr/lib/systemd".
Thanks.
Quis separabit? Quo animo?
I guess you could try
Code: Select all
$ emerge -vp /usr/lib/systemdThanks, I never think of being able to do that. Unfortunately it didn't work, but it reminded me that binary packages contain what they install. Apparently only gnupg and pam need reinstalling.asturm wrote:I guess you could try
Code: Select all
$ emerge -vp /usr/lib/systemd
Quis separabit? Quo animo?