Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 25/02/14 15:26, Thomas D. wrote: > No, not locations. My choice was not to use systemd. Now a package, > sys-fs/udev, turns into systemd-udev... > > Also: If it wouldn't be possible to keep sys-fs/udev as it was I > wouldn't bother that much. But as said, Lars (Polynomial-C) showed us > that we don't need to turn sys-fs/udev into systemd-udev... > > So I am asking why we are doing that for people who don't use systemd? Nobody is doing anything except using upstream names for those files and directories as defined in the Makefile.am I can't speak for everybody, but in general, we are not in the business of randomly changing things when there is no technical reason for it I couldn't care less about the so called 'pro-systemd', or 'anti-systemd' propaganda that's out there. And nobody can influence me with that crap for udev's maintenance. I'm completely neutral to that spat, and even if I weren't, I wouldn't bring that crap over to udev's maintenance. What requires to be done will be done, to keep the functionality up-par with the sys-fs/udev-171 we had as longstanding version before. Only technical arguments have weight.
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 02/26/2014 6:44 AM, Peter Stuge wrote:
> Joshua Kinard wrote:
>> Most future Linux systems that are based off of mainstream
>> distributions will *have* to use systemd+udev in order to
>> achieve maximum functionality.
>
> Certainly!
Clarification: I wasn't implying that that was entirely a good thing,
however. But that's just my opinion.
> And I think the reason systemd gains traction is that such maximum
> functionality can easily include various things which aren't available
> and more difficult with other choices.
I would argue that it gains traction more by providing APIs that only it can
implement. However efficient or sensible these APIs might be, when major,
upstream software projects use those APIs, you are then left with two
choices: switch to systemd+udev or lose the functionality offered by
${MAJOR_UPSTREAM_PROJECT}. udev was the first example of this, and more
will follow in time.
> It just means that many have a changed mindset and want something else.
Many != Everyone, though. But, when you're in the minority, I guess that's
not really relevant. Majority takes all. C'est la vie.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On Wed, Feb 26, 2014 at 5:49 AM, Thomas D. wrote: > > I don't see a need for mentioning that the actual configuration is > located in "/lib/systemd/network/..." in the NEWS item. I think it makes sense to keep this in. If somebody doesn't like the default persistent naming conventions then they'll either want to disable it entirely or modify it. If they want to disable it, the best way to do it is from the kernel parameters. If they want to modify it, the best way is via the config files. Their location isn't at all intuitive to somebody for which this is NEWS, and assuming no work has been done to date it makes more sense to start there than to start hacking away at the rules. Granted, by now any such hacking is long done, but perhaps some who have disabled the rules entirely might now want to consider looking at the config file to see if they can be tamed. Rich
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Joshua Kinard wrote: > Most future Linux systems that are based off of mainstream > distributions will *have* to use systemd+udev in order to > achieve maximum functionality. Certainly! And I think the reason systemd gains traction is that such maximum functionality can easily include various things which aren't available and more difficult with other choices. That doesn't mean that sysvinit doesn't do fine what it has always done. It just means that many have a changed mindset and want something else. //Peter
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 02/25/2014 8:24 AM, Samuli Suominen wrote: > > If someone is willing to change his device manager because a file or > directory name is 'systemd', then by all means, sounds very logical > system maintaince, not. > > - Samuli There is actually a kind of psychological effect on doing it this way, one to which I have to give credit to upstream for employing (whether they intended to or not). By having udev put things into directories that would also be used by systemd, if it was installed, it reminds people of the inevitability that one day, systemd will be the only viable init choice to boot a Linux system and make the userland functional. This is why you're witnessing some people reacting by switching out their device manager over a silly directory name. That's the psychology working. Debian's recent vote on the default init system in jessie is just further affirmation that, sysvinit is deprecated (last release was almost 4 years ago, too). Most future Linux systems that are based off of mainstream distributions will *have* to use systemd+udev in order to achieve maximum functionality. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Hi, I like your (Alex) new proposal, but I have the following annotations: > As of sys-fs/udev-210, the options CONFIG_FHANDLE and CONFIG_NET > are now required in the kernel. A warning will be issued if they > are missing when you upgrade. See the package's README in > /usr/share/doc/udev-210/ for more optional kernel options. Isn't that a chicken/egg problem? I see the NEWS when I have Overriding the 80-net-name-slot.rules in /etc/udev/rules.d/ no > longer works since upstream renamed the file to > /lib/udev/rules.d/80-net-setup-link.rules. All I have to do is changing the name from "80-net-name-slot.rules" to "80-net-setup-link.rules", e.g. adjusting the name because upstream renamed... not? So a text like The most reliable way of disabling the new network interface scheme is still the kernel parameter "net.ifnames=0". If you are using the "net-name-slot.rules" approach make sure you adapt the new naming before you restart because upstream renamed the "80-net-name-slot.rules" to "80-net-setup-link.rules". sounds better for me instead of saying "overriding no longer works" and to clarify later that this is still possible ;) I don't see a need for mentioning that the actual configuration is located in "/lib/systemd/network/..." in the NEWS item. -Thomas
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Title: >=sys-fs/udev-210 upgrade Author: Samuli Suominen Content-Type: text/plain Posted: 2014-02-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210 [2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On Tue, Feb 25, 2014 at 7:32 AM, Rich Freeman wrote: > I haven't looked into the details as to why a config file is stored in > /lib/systemd, but I imagine that they're trying to store settings in > one place and have them applied to multiple executables (though > obviously by overriding the rule you could change this). That isn't a > bad goal. > Exactly right: The /lib/systemd/network directory is primarily used by systemd-networkd. udev just happens to use a few of the same settings.
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On Tue, Feb 25, 2014 at 8:26 AM, Thomas D. wrote: > Rich Freeman wrote: >> On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. wrote: >>> Also, I cannot belief that I cannot overwrite >>> "/lib/udev/rules.d/80-net-setup-link.rules" via "/etc/udev/rules.d"... >> >> I don't see why not - from the news item: >> So, to clarify, you can override the new .rules file or the .link file in >> /etc >> but using the kernel parameter is the most consistent way. > > Maybe I am wrong, but when talking about kernel parameter we are talking > only about > >net.ifnames= > > right? > > So with this parameter we can only disable the new naming, right? Correct. > > My fear is that all my routers and servers with multiple interfaces > won't come up anymore after the upgrade because they don't have my > custom names anymore because due to the new rule, udev didn't or failed > to rename... The rule is called 80-net-setup-link.rules, so stick a file called that in /etc/udev/rules.d/ and you should be able to do anything you want. Again, I haven't studied this in detail, but unless somebody has changed something fundamental in how udev works that is the answer. > Have you read documentation? It is not about locations at all... my > problem is that it seems like that I have to use a new syntax from > systemd-udev when doing something in "/etc/systemd" but as said: I am > using sys-fs/udev, I don't care about systemd... why should I learn > systemd when I am only using udev? I haven't read the documentation, but I gather from the news item that a udev rules script is reading settings from a config file. If you want to use the fancy new magic config file, then obviously you need to use whatever syntax it operates under. If you just want to replace the udev rule, then I'd think that you could do that basically the same way you've always done it, unless the actual syntax of the rules is changing (which I suspect is unlikely). > Polynomical-C doesn't uses much patches... no, the magic is in the > ebuild. Upstream still supports the "old" usage... it is the Gentoo > ebuild which turns the package into systemd-udev... Bottom line is that upstream is doing it one way, and we have various people who want udev to behave differently in Gentoo. Take your pick, nobody is preventing polynomial-c from sticking his version in the main tree, and eudev is already there. Apparently there is an expectation that other packages may expect the file to be in the place upstream installs it. If that is the case then anybody wanting to use those packages would probably want to keep the files where upstream places them. However, I imagine that this will end up being a concern more for systemd and perhaps other packages that require it (Gnome, etc). > And that's what I meant when I said "give something 'back'": It should > be possible to create an ebuild for systemd and non-systemd users. Yes, > more maintenance is needed. But taking a package which was working fine > for non-systemd users and transform it into a systemd package isn't nice > and fair. I understand the frustration, but this really just reflects what upstream is doing. The old behavior has been forked back into packages like eudev, or polynomial-c's overlay. There is nothing wrong with using those packages, though it might cause issues if you use anything else which expects the new behavior out of udev. The trend is towards more vertical integration, so that might be more of a problem than it has been in the past. If the systemd folks had forked udev and called it something else I doubt there would be any complaining at all. Instead the upstream udev took off in a different direction. I know I've heard the word "takeover" used, but my understanding is that this isn't really what happened. Like Gnome the team (or whatever was left of it) just decided to move in a different direction. To them this stuff isn't controversial, and they don't feel like they have to give anything back, since they're the ones who gave it all in the first place. Rich
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 25/02/14 14:18, Joshua Kinard wrote:
> On 02/25/2014 6:39 AM, Thomas D. wrote:
>> Hi,
>>
>> line 16 ("renamed the file to
>> /lib/udev/rules.d/80-net-setup-link.rules") and line 18 ("you can
>> override in /etc/systemd/network/") doesn't end with punctuation.
>>
>>
>> Did I get this right? I am using udev to give my interfaces custom names
>> and I am not a systemd user but to keep my setup working with udev-210 I
>> have to exclude
>>
>> /lib/systemd/network/
>> /etc/systemd/
>>
>> from my INSTALL_MASK *and* I have to configure things in
>> "/etc/systemd/"? Really?
> "Resistance is futile."
> "Freedom is irrelevant. Self-determination is irrelevant. You must comply."
> -- The Borg Collective
>
> "You will be upgraded."
> "You will become like us."
> -- Cybermen
>
>
>> Anyway:
>> Don't get me wrong. Yes, I don't use systemd and I am a happy OpenRC
>> user but I have no problems with systemd (as long as it doesn't affects
>> me). But this upgrade seems to affect non-systemd users.
>>
>> Wasn't Gentoo about choices?
>>
>> So when it is possible to provide a sys-fs/udev package like Lars
>> (Polynomial-C) has shown which won't require non-systemd user to use
>> files from systemd and to do configuration in "/etc/systemd/" why don't
>> we provide such a package to non-systemd users?
>> The package already has an "openrc" USE flag...
> There still is choice. It's just harder to find and/or use, unfortunately.
> We have the sys-fs/eudev package that forked udev and re-split it out of
> systemd. That might satisfy your need for a clean replacement of the
> standard udev w/o modifying any custom device rules and such that you might
> have.
>
> There's also the option of using busybox's mdev as well, although it's a lot
> more limited and no where near as configurable as udev/eudev is. But for
> some, it works perfectly (like me).
>
> Eudev:
> https://wiki.gentoo.org/wiki/Project:Eudev
>
> Mdev:
> https://wiki.gentoo.org/wiki/Mdev
>
If someone is willing to change his device manager because a file or
directory
name is 'systemd', then by all means, sounds very logical system maintaince,
not.
- Samuli
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Hi, Rich Freeman wrote: > On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. wrote: >> Also, I cannot belief that I cannot overwrite >> "/lib/udev/rules.d/80-net-setup-link.rules" via "/etc/udev/rules.d"... > > I don't see why not - from the news item: > So, to clarify, you can override the new .rules file or the .link file in /etc > but using the kernel parameter is the most consistent way. Maybe I am wrong, but when talking about kernel parameter we are talking only about net.ifnames= right? So with this parameter we can only disable the new naming, right? But as said, I am using udev to name my interfaces -- the new kernel naming isn't my problem. I don't understand how this should help me. My fear is that all my routers and servers with multiple interfaces won't come up anymore after the upgrade because they don't have my custom names anymore because due to the new rule, udev didn't or failed to rename... >> Don't get me wrong. Yes, I don't use systemd and I am a happy OpenRC >> user but I have no problems with systemd (as long as it doesn't affects >> me). But this upgrade seems to affect non-systemd users. >> > > The only thing that changed is the location where a config setting is > stored. Nobody has to use systemd as a sysvinit replacement. Have you read documentation? It is not about locations at all... my problem is that it seems like that I have to use a new syntax from systemd-udev when doing something in "/etc/systemd" but as said: I am using sys-fs/udev, I don't care about systemd... why should I learn systemd when I am only using udev? >> Wasn't Gentoo about choices? > > Well, we generally don't give users a choice in where config files are > installed. No, not locations. My choice was not to use systemd. Now a package, sys-fs/udev, turns into systemd-udev... Also: If it wouldn't be possible to keep sys-fs/udev as it was I wouldn't bother that much. But as said, Lars (Polynomial-C) showed us that we don't need to turn sys-fs/udev into systemd-udev... So I am asking why we are doing that for people who don't use systemd? Polynomical-C doesn't uses much patches... no, the magic is in the ebuild. Upstream still supports the "old" usage... it is the Gentoo ebuild which turns the package into systemd-udev... And that's what I meant when I said "give something 'back'": It should be possible to create an ebuild for systemd and non-systemd users. Yes, more maintenance is needed. But taking a package which was working fine for non-systemd users and transform it into a systemd package isn't nice and fair. You get my point? -Thomas
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. wrote: > Also, I cannot belief that I cannot overwrite > "/lib/udev/rules.d/80-net-setup-link.rules" via "/etc/udev/rules.d"... I don't see why not - from the news item: So, to clarify, you can override the new .rules file or the .link file in /etc but using the kernel parameter is the most consistent way. > Don't get me wrong. Yes, I don't use systemd and I am a happy OpenRC > user but I have no problems with systemd (as long as it doesn't affects > me). But this upgrade seems to affect non-systemd users. > The only thing that changed is the location where a config setting is stored. Nobody has to use systemd as a sysvinit replacement. > Wasn't Gentoo about choices? Well, we generally don't give users a choice in where config files are installed. > Now it seems like it is time to give something "back", => make sure a > change required for systemd doesn't hurt non-systemd users. Not really sure how you're defining "hurt" here. Whether you use systemd or not udev moved a config file. This sort of thing happens on occasion in many packages (one of these days I need to clean out /etc/apache2 as I can never remember which files are actually sourced). Sure, it is annoying and should be avoided when practical, but I don't think it makes sense to deviate from what upstream is doing here. I haven't looked into the details as to why a config file is stored in /lib/systemd, but I imagine that they're trying to store settings in one place and have them applied to multiple executables (though obviously by overriding the rule you could change this). That isn't a bad goal. Rich
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 02/25/2014 6:39 AM, Thomas D. wrote:
> Hi,
>
> line 16 ("renamed the file to
> /lib/udev/rules.d/80-net-setup-link.rules") and line 18 ("you can
> override in /etc/systemd/network/") doesn't end with punctuation.
>
>
> Did I get this right? I am using udev to give my interfaces custom names
> and I am not a systemd user but to keep my setup working with udev-210 I
> have to exclude
>
> /lib/systemd/network/
> /etc/systemd/
>
> from my INSTALL_MASK *and* I have to configure things in
> "/etc/systemd/"? Really?
"Resistance is futile."
"Freedom is irrelevant. Self-determination is irrelevant. You must comply."
-- The Borg Collective
"You will be upgraded."
"You will become like us."
-- Cybermen
> Anyway:
> Don't get me wrong. Yes, I don't use systemd and I am a happy OpenRC
> user but I have no problems with systemd (as long as it doesn't affects
> me). But this upgrade seems to affect non-systemd users.
>
> Wasn't Gentoo about choices?
>
> So when it is possible to provide a sys-fs/udev package like Lars
> (Polynomial-C) has shown which won't require non-systemd user to use
> files from systemd and to do configuration in "/etc/systemd/" why don't
> we provide such a package to non-systemd users?
> The package already has an "openrc" USE flag...
There still is choice. It's just harder to find and/or use, unfortunately.
We have the sys-fs/eudev package that forked udev and re-split it out of
systemd. That might satisfy your need for a clean replacement of the
standard udev w/o modifying any custom device rules and such that you might
have.
There's also the option of using busybox's mdev as well, although it's a lot
more limited and no where near as configurable as udev/eudev is. But for
some, it works perfectly (like me).
Eudev:
https://wiki.gentoo.org/wiki/Project:Eudev
Mdev:
https://wiki.gentoo.org/wiki/Mdev
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Hi,
line 16 ("renamed the file to
/lib/udev/rules.d/80-net-setup-link.rules") and line 18 ("you can
override in /etc/systemd/network/") doesn't end with punctuation.
Did I get this right? I am using udev to give my interfaces custom names
and I am not a systemd user but to keep my setup working with udev-210 I
have to exclude
/lib/systemd/network/
/etc/systemd/
from my INSTALL_MASK *and* I have to configure things in
"/etc/systemd/"? Really?
Also, I cannot belief that I cannot overwrite
"/lib/udev/rules.d/80-net-setup-link.rules" via "/etc/udev/rules.d"...
Anyway:
Don't get me wrong. Yes, I don't use systemd and I am a happy OpenRC
user but I have no problems with systemd (as long as it doesn't affects
me). But this upgrade seems to affect non-systemd users.
Wasn't Gentoo about choices?
So when it is possible to provide a sys-fs/udev package like Lars
(Polynomial-C) has shown which won't require non-systemd user to use
files from systemd and to do configuration in "/etc/systemd/" why don't
we provide such a package to non-systemd users?
The package already has an "openrc" USE flag...
Remember that the non-systemd folk in Gentoo is doing a lot to help you
(the systemd folk) to add proper systemd support in Gentoo. Now it seems
like it is time to give something "back", => make sure a change required
for systemd doesn't hurt non-systemd users.
Thanks.
-Thomas
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 25/02/14 13:03, Joshua Kinard wrote: > On 02/25/2014 5:27 AM, Steev Klimaszewski wrote: >> On Tue, 2014-02-25 at 10:43 +0200, Samuli Suominen wrote: >>> Here is a bit better worded news item for the upgrade. I think I've >>> taken into account any concerns, but please check >>> the grammar part. Thanks! >>> >>> - Samuli >> CONFIG_DMIID isn't available for ARM. Can we make that warning go away >> if on ARM, so users don't pull their hair out? >> > This might be an x86 and ia64-specific CONFIG_* item: > > Symbol: DMIID [=y] > Type : boolean > Prompt: Export DMI identification via sysfs to userspace > Location: > -> Firmware Drivers > Defined at drivers/firmware/Kconfig:91 > Depends on: DMI [=y] > > Symbol: DMI [=y] > Type : boolean > Prompt: Enable DMI scanning > Location: > -> Processor type and features > Defined at arch/x86/Kconfig:748 > > > # grep -rIn "config DMI" * > arch/ia64/Kconfig:104:config DMI > arch/x86/Kconfig:748:config DMI > drivers/firmware/Kconfig:91:config DMIID > drivers/firmware/Kconfig:100:config DMI_SYSFS > > So all non-x86/ia64 systems (amd64/x86_64, too??) probably need to ignore > this CONFIG_* item. > After more close look, the feature looks more optional than at first sight. I've dropped the entire check from ebuild and leaned the text in the news announcement. This should do it... Title: Upgrade to >=sys-fs/udev-210 Author: Samuli Suominen Content-Type: text/plain Posted: 2014-02-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =sys-fs/udev-210 by the package manager. See the package's README at /usr/share/doc/udev-210/ for more optional kernel options. The most reliable way of disabling the new network interface scheme is still the kernel parameter "net.ifnames=0" since overriding the 80-net-name-slot.rules in /etc/udev/rules.d/ no longer works since upstream renamed the file to /lib/udev/rules.d/80-net-setup-link.rules The actual configuration is at /lib/systemd/network/99-default.link, which you can override in /etc/systemd/network/ So, to clarify, you can override the new .rules file or the .link file in /etc but using the kernel parameter is the most consistent way. Since both the systemd-udevd executable and the network configuration is stored at /lib/systemd, using a too wide INSTALL_MASK would be a mistake. [1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210 [2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 02/25/2014 5:27 AM, Steev Klimaszewski wrote: > On Tue, 2014-02-25 at 10:43 +0200, Samuli Suominen wrote: >> Here is a bit better worded news item for the upgrade. I think I've >> taken into account any concerns, but please check >> the grammar part. Thanks! >> >> - Samuli > > CONFIG_DMIID isn't available for ARM. Can we make that warning go away > if on ARM, so users don't pull their hair out? > This might be an x86 and ia64-specific CONFIG_* item: Symbol: DMIID [=y] Type : boolean Prompt: Export DMI identification via sysfs to userspace Location: -> Firmware Drivers Defined at drivers/firmware/Kconfig:91 Depends on: DMI [=y] Symbol: DMI [=y] Type : boolean Prompt: Enable DMI scanning Location: -> Processor type and features Defined at arch/x86/Kconfig:748 # grep -rIn "config DMI" * arch/ia64/Kconfig:104:config DMI arch/x86/Kconfig:748:config DMI drivers/firmware/Kconfig:91:config DMIID drivers/firmware/Kconfig:100:config DMI_SYSFS So all non-x86/ia64 systems (amd64/x86_64, too??) probably need to ignore this CONFIG_* item. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On Tue, 2014-02-25 at 10:43 +0200, Samuli Suominen wrote: > Here is a bit better worded news item for the upgrade. I think I've > taken into account any concerns, but please check > the grammar part. Thanks! > > - Samuli CONFIG_DMIID isn't available for ARM. Can we make that warning go away if on ARM, so users don't pull their hair out? The first sentence in the second paragraph doesn't have a period at the end, and using "since" twice sounds odd to me when I read it out loud, but I don't think it's that big of an issue. Not related to the news file, since you aren't upstream, but wtf? They store *configuration* there as well? Or is that just a mis-wording? I'd also say, "using too wide of an INSTALL_MASK would be a mistake." instead of "using a too wide INSTALL_MASK would be a mistake."
[gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Here is a bit better worded news item for the upgrade. I think I've taken into account any concerns, but please check the grammar part. Thanks! - Samuli Title: Upgrade to >=sys-fs/udev-210 Author: Samuli Suominen Content-Type: text/plain Posted: 2014-02-25 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =sys-fs/udev-210 by the package manager. The most reliable way of disabling the new network interface scheme is still the kernel parameter "net.ifnames=0" since overriding the 80-net-name-slot.rules in /etc/udev/rules.d/ no longer works since upstream renamed the file to /lib/udev/rules.d/80-net-setup-link.rules The actual configuration is at /lib/systemd/network/99-default.link, which you can override in /etc/systemd/network/ So, to clarify, you can override the new .rules file or the .link file in /etc but using the kernel parameter is the most consistent way. Since both the systemd-udevd executable and the network configuration is stored at /lib/systemd, using a too wide INSTALL_MASK would be a mistake. [1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210 [2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
