I have read the News item several times, but still don't understand the second and third options.

If I understand correctly, you are saying that a file /etc/udev/rules.d/80-net-name-slot.rules containing just a comment will no longer work and there are now the following two options if one does not use the kernel parameter method:

- Create a file /etc/udev/rules.d/80-net-setup-link.rules containing just a comment,

or, alternatively,

- create a file /etc/systemd/network/99-default.link containing just a comment.

Is my understanding correct? If not, will you please specify the precise file names, including full paths, and the file contents, to avoid any doubt. Thanks in advance.

That seems to be an ongoing problem, either you get no notification and thus have to start threads here
or you get confusing and not very well thought out news articles and have to start threads here for clarification.

The proper thing to do would be something similar to what happens in the real world.
Hand it to a documentation person and see what they say about it.
Barring that (if they're not available) then start a thread yourself, or ask one
or two of the people (via pm) on threads like this if the prototype news is clear or not.
It's not rocket science.

A large part of the problem with news articles like this is the person, usually a dev,
understands what he's trying to say, but doesn't take into account that others
don't have their level of understanding of what they're trying to communicate._________________Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon

I can't be entirely specific but CONFIG_NET is used by systemd-udevd itself (the udev daemon executable) and CONFIG_FHANDLE is used by libudev.so.1

Ok, I have fhandle in my kernel now. Still I don't know wether udev-208 works without systemd.
The news item is not very clear about that just says:

Quote:

The actual configuration is at /lib/systemd/network/99-default.link, which
you can override in /etc/systemd/network/

And of course I don't have the path "/etc/systemd/network".

I don't understand where you got the idea that sys-fs/udev would be requiring systemd. That's not true at all. Also, the news item is for upgrading into >=sys-fs/udev-210, so while you are still at
=sys-fs/udev-208 or older, the news thread is irrelevant for you.

I know I may be playing the devil's advocate here but please, don't shoot the messenger.

The news items has been posted with plenty of time to prepare (at least for stable tree users), it suggests not one but two ways to keep "classic" interface names, and it even warns against using a too general INSTALL_MASK, when it shouldn't have to, strictly speaking. Also, no matter how I read it, it can't seem to find a place where the news item talks about systemd as a mandatory dependency.

I have no love at all for systemd and I plan to stop using udev as soon as it requires systemd, an eventuality which by the look of things I'm afraid is almost certain to happen, and rather soon, (I mean, if upstream had little regard for keeping things easy for upstart, does anyone really expect them to keep udev working for openrc in the medium/long term?) however, I find this news item clear, concise and useful, specially for people not running systemd.

I know I may be playing the devil's advocate here but please, don't shoot the messenger.
...
however, I find this news item clear, concise and useful, specially for people not running systemd.

I understood what he was saying, but I was a programmer for a long time.
I do beg to differ, it wasn't that clear, concise, yes, useful, maybe.
If it had been clear, then this thread with attendant questions would not have happened.

I was also aware that systemd wasn't required, but since he threw in mention of it,
without clarification, that caused some of the confusion. Me, I just looked at the ebuild.
Devs aren't known for being very good documentation people.
But you have to understand the audience that you are writing for even with news blurbs OR be prepared to answer lots of questions._________________Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon

I know I may be playing the devil's advocate here but please, don't shoot the messenger.

The news items has been posted with plenty of time to prepare (at least for stable tree users), it suggests not one but two ways to keep "classic" interface names, and it even warns against using a too general INSTALL_MASK, when it shouldn't have to, strictly speaking. Also, no matter how I read it, it can't seem to find a place where the news item talks about systemd as a mandatory dependency.

I have no love at all for systemd and I plan to stop using udev as soon as it requires systemd, an eventuality which by the look of things I'm afraid is almost certain to happen, and rather soon, (I mean, if upstream had little regard for keeping things easy for upstart, does anyone really expect them to keep udev working for openrc in the medium/long term?) however, I find this news item clear, concise and useful, specially for people not running systemd.

Err, it's the otherway around, it's the service manager (systemd) which needs device manager (udev) -- which is why sys-apps/systemd has it's own internal copy of udev.
So you don't have to worry about sys-fs/udev, there is no need for device manager to start requiring a specific service manager -- udev dooesn't care what starts it.

I expect sys-fs/udev to be in Portage (and the default) for long as sys-apps/openrc is in Portage (and the default), as in, it's not going anywhere. I'll stop maintaining sys-fs/udev if sys-apps/systemd becomes the default, but that hasn't been even a topic yet, and propably never will be due to it's non-portability.

With the update to udev-210, I rebuilt my kernel with CONFIG_FHANDLE and CONFIG_NET.
I need an initramfs to boot, my boot partition is on a hdd and my rootfs is on a ssd and the /dev/sd* names change regularly with my usb-disks. With an initramfs I can specify the rootfs as UUID.

Normally I create an initramfs with dracut but with udev-210 I get a "Cannot find [systemd-]udevd binary!" error. I made an initramfs with genkernel and that worked, all went well after reboot._________________i7-4790K | 16GB DDR3 | GTX 970 | 500GB SSD
ASUS N56VV | i7-3630QM | 12GB DDR3 | GT 750M | 256GB SSD

Err, it's the otherway around, it's the service manager (systemd) which needs device manager (udev) -- which is why sys-apps/systemd has it's own internal copy of udev.
So you don't have to worry about sys-fs/udev, there is no need for device manager to start requiring a specific service manager -- udev dooesn't care what starts it.

Yes, I know it's the other way around, right now. However, it is my impression that systemd devs now see themselves as the owners of the only relevant init system for the only relevant UNIX descendant, and since they also maintain udev, the temptation not to keep it decoupled from the service manager may be too hard to resist.

Straight from the horse's mouth: "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." With upstart disappearing in the near future, I'm afraid that day is arriving rather soon.

Where have you been the last few years? udev is no more or less doomed today than it was when it got merged into the systemd tarball. You are merely duplicating the whirl we had when that happened. However, udev so far still works fine by itself._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Well, with everyone on systemd and systemd using its internal udev, there would be nothing to maintain and nobody to maintain it for would there ... apart from the non systemd users.

The cynic in me reads that as unless someone steps up to maintain udev should Gentoo switch to systemd as a default, udev will be dead on Gentoo.
That about confirms that udev is a dead end and that users wishing to avoid systemd should evaluate udev replacements.

Ah well, just as well a device manager free system still works._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

It's not hard to read a postinst message and then forget about it, but reading an official Portage news item that's meant for critical messaging can't be just shoved off by 'I forgot, and now I will blame others.'
As in, there is a world of difference between Package postinst messages and the Portage news items.

A postinst message is not going to be read when there have been enough messages that is off the screen and out of the scroll back buffer. That should not be hard to understand. Postinst message are not always going to be seen. News items can be read and forgotten about. Not hard to read something then forget about it 2 - 3 months later which is when the 204 upgrade bit me.

I still maintain it was stupid having a package install even when it will kill a working system. Also as I said before udev aborting the boot sequence when it has a problem on a computer that is capable of booting without udev running does not help. From problems the 204 upgrades caused people, the unpredictable network names and your udev should upgrade regardless attitude I do no trust udev upgrades._________________Beware the grue.

Where have you been the last few years? udev is no more or less doomed today than it was when it got merged into the systemd tarball. You are merely duplicating the whirl we had when that happened. However, udev so far still works fine by itself.

You are missing the point. With systemd infiltrating more and more linux distributions -including gentoo- things are today
far more worse and doomed then they used to be when udev was included into the systemd tarball.

The cynic in me reads that as unless someone steps up to maintain udev should Gentoo switch to systemd as a default, udev will be dead on Gentoo.
That about confirms that udev is a dead end and that users wishing to avoid systemd should evaluate udev replacements.

Pretty much, despite the labeling of those who saw this coming as conspiracists.

Quote:

Ah, just as well a device manager free system still works.

Yep.

Udev worked well in the past before the systemd people managed to take control of it.
I doubt very seriously that the previous maintainers thought that this would happen.
I'm hoping that the kernel people will just do the right thing and put a simplified udev into the kernel._________________Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon

You are missing the point. With systemd infiltrating more and more linux distributions -including gentoo- things are today
far more worse and doomed then they used to be when udev was included into the systemd tarball.

...my point being that development was foreseeable back then already. And I suspect that a continued upstart effort wouldn't have changed much in that regard._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

You are missing the point. With systemd infiltrating more and more linux distributions -including gentoo- things are today
far more worse and doomed then they used to be when udev was included into the systemd tarball.

...my point being that development was foreseeable back then already. And I suspect that a continued upstart effort wouldn't have changed much in that regard.

No one foresaw the stubbornness of the systemd people pushing their case forward.
They were too long underestimated concerning their negative and malicious efforts
concerning the whole linux community. Now or never is the time to deal with them.

No one foresaw the stubbornness of the systemd people pushing their case forward.
They were too long underestimated concerning their negative and malicious efforts
concerning the whole linux community. Now or never is the time to deal with them.

As I said, same discussion we had back then._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

No one foresaw the stubbornness of the systemd people pushing their case forward.
They were too long underestimated concerning their negative and malicious efforts
concerning the whole linux community. Now or never is the time to deal with them.

As I said, same discussion we had back then.

May be, but today we know what happened in the meantime and what will probably happen soon.
So far it is a different situation.

Nothing changed today that we didn't know yesterday already. And when udev finally won't work standalone tomorrow, someone can still fork it. Or move to alternative dev management that has existed all the while. So far, however, udev still works perfectly fine._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

No one foresaw the stubbornness of the systemd people pushing their case forward.

No, there were some of us who saw what was going to happen, despite the lies of a dev and sycophants.
What so upsets people is that some of us saw through the lies.

Right now it's very obvious to many that udev is about to be subsumed within systemd.
And just like logind there won't be something separate, there soon won't be a choice except to take the whole ball of wax.
If people want to accept that, I don't care, any more than I care that people want to use some flavor of windows or apple product.
But it's bloody obvious what is coming down the road.
I despise people who try and lie to me and tell me I'm too stupid to see what's coming when it's obvious._________________Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
4.14.62 kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 7.3.0, eudev, openrc, openbox, palemoon

You don't seem to understand what should, and what should't be fatal. What if I'm building my udev on a different machine and then deploy the created binary package to another machine, which in fact has a kernel with all the latest and greatest requrements enabled? Then what does it matter what options you have enabled in the build host? None, whatsoever.
So what you are suggesting would completely kill off the consept of creating binary packages on a another machine (build host) which Portage has supported for years.
If you don't read news items, or warnings of missing kernel features from the Portage, that's really completely your own fault, called poor administration.

Hear hear! Being able to build on a binhost is a great thing and we should take care that we can continue to do that reliably in the future. It's a wonderful technique that I'm using more and more since it maximizes the usability of my production machines.

Binary packages still include all the installation-time testing. Emerging them still writes message to the log. The install-time tests would be a really opportune place to check for kernel options. I agree that it is quite unwise to ignore the elog messages. I always prefer building new systems by ssh'ing into them for this reason: I can have a long scrollback buffer in my terminal window. There are all kinds of useful things lurking in those messages--a thing I've learned through unhappy experience.

(Another technique for capturing those messages is in screen. You can use that quite well if even you are working at a framebuffer.)

I don't know if an ebuild can be made to fail in the installation-test phase; if ebuilds can, it might be helpful here. Certainly, though, a news item for this kind of thing would be very welcome.

Lest you find my answer too agreeable, let me point out that I'm a happy eudev user. I avoid a lot of drama that way.

Nothing changed today that we didn't know yesterday already. And when udev finally won't work standalone tomorrow, someone can still fork it. Or move to alternative dev management that has existed all the while. So far, however, udev still works perfectly fine.

There already is such a fork, eudev. At least one developer participating in this thread is openly hostile to that fork. Works great for me, and I get to avoid much of the drama. It's like udev minus certain unnecessary changes.