[gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)

[gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

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

[-- Attachment #2: 2014-02-25-udev-upgrade.en.txt --]
[-- Type: text/plain, Size: 1225 bytes --]

Title: Upgrade to >=sys-fs/udev-210
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2014-02-25
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-210

The options CONFIG_DMIID and CONFIG_FHANDLE, CONFIG_NET are now required
in the kernel. You will be warned of them if they are missing while you
upgrade to >=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

Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)

[Steev Klimaszewski]

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."

Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)

[Joshua Kinard]

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
kumba@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)

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]


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...

[-- Attachment #2: 2014-02-25-udev-upgrade.en.txt --]
[-- Type: text/plain, Size: 1298 bytes --]

Title: Upgrade to >=sys-fs/udev-210
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2014-02-25
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-210

The options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel.
You will be warned of them if they are missing while you upgrade to
>=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

[gentoo-dev] Re: News draft #2 for the udev-210 upgrade (was: 209 upgrade)

[Duncan]

Samuli Suominen posted on Tue, 25 Feb 2014 10:43:15 +0200 as excerpted:

> Here is a bit better worded news item for the upgrade. 

Looks much better, thanks. =:^)

But...

> The options CONFIG_DMIID

Umm... "Don't Mind if I do"?  That's what google says about DMIID, and 
there's nothing about it on the linked wiki.g.o udev upgrade page.

If I don't remember reading of it before, I believe it's a fair bet most 
gentooers don't have a clue either, so a bit of explanation about just 
what it is we're being asked to enable might be nice! =:^)

(At least the other two, net and fhandle, make a bit of intuitive sense.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)

[Thomas D.]

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)

[Joshua Kinard]

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
kumba@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)

[Rich Freeman]

On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. <whissi@whissi.de> 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)

[Samuli Suominen]

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)

[Thomas D.]

Hi,

Rich Freeman wrote:
> On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. <whissi@whissi.de> 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)

[Rich Freeman]

On Tue, Feb 25, 2014 at 8:26 AM, Thomas D. <whissi@whissi.de> wrote:
> Rich Freeman wrote:
>> On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. <whissi@whissi.de> 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)

[Mike Gilbert]

On Tue, Feb 25, 2014 at 7:32 AM, Rich Freeman <rich0@gentoo.org> 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)

[Alex Xu]

[-- Attachment #1.1: Type: text/plain, Size: 2 bytes --]



[-- Attachment #1.2: udev-upgrade.en.txt --]
[-- Type: text/plain, Size: 1427 bytes --]

Title: >=sys-fs/udev-210 upgrade
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2014-02-25
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-210

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.

The most reliable way of disabling the new network interface scheme is still
the kernel parameter "net.ifnames=0". 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 reliable way.

If you are using sys-fs/udev, you must not use an INSTALL_MASK including
"/lib/systemd". If you wish to mask unit files, use
INSTALL_MASK="/lib/systemd/system". If, for some reason, you do not want any
directory named "systemd" on your disk, use a different device manager, like
sys-fs/eudev or sys-fs/mdev.

[1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_210
[2] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)

[Thomas D.]

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
<sys-fs/udev-210 installed. The NEWS tells me to read the README in
"/usr/share/doc/udev-210/" for more options. But until I upgraded I
cannot access the README..

So if these options are important, make them available in the Wiki or
somewhere else and link to that resource.

If these options are not important, remove the sentences because it
doesn't add any usable information to that NEWS item.


> 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)

[Joshua Kinard]

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
kumba@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)

[Peter Stuge]

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)

[Rich Freeman]

On Wed, Feb 26, 2014 at 5:49 AM, Thomas D. <whissi@whissi.de> 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]

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
kumba@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)

[Samuli Suominen]

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.