| 1 |
On Tue, Feb 25, 2014 at 8:26 AM, Thomas D. <whissi@××××××.de> wrote: |
| 2 |
> Rich Freeman wrote: |
| 3 |
>> On Tue, Feb 25, 2014 at 6:39 AM, Thomas D. <whissi@××××××.de> wrote: |
| 4 |
>>> Also, I cannot belief that I cannot overwrite |
| 5 |
>>> "/lib/udev/rules.d/80-net-setup-link.rules" via "/etc/udev/rules.d"... |
| 6 |
>> |
| 7 |
>> I don't see why not - from the news item: |
| 8 |
>> So, to clarify, you can override the new .rules file or the .link file in /etc |
| 9 |
>> but using the kernel parameter is the most consistent way. |
| 10 |
> |
| 11 |
> Maybe I am wrong, but when talking about kernel parameter we are talking |
| 12 |
> only about |
| 13 |
> |
| 14 |
> net.ifnames= |
| 15 |
> |
| 16 |
> right? |
| 17 |
> |
| 18 |
> So with this parameter we can only disable the new naming, right? |
| 19 |
|
| 20 |
Correct. |
| 21 |
|
| 22 |
> |
| 23 |
> My fear is that all my routers and servers with multiple interfaces |
| 24 |
> won't come up anymore after the upgrade because they don't have my |
| 25 |
> custom names anymore because due to the new rule, udev didn't or failed |
| 26 |
> to rename... |
| 27 |
|
| 28 |
The rule is called 80-net-setup-link.rules, so stick a file called |
| 29 |
that in /etc/udev/rules.d/ and you should be able to do anything you |
| 30 |
want. |
| 31 |
|
| 32 |
Again, I haven't studied this in detail, but unless somebody has |
| 33 |
changed something fundamental in how udev works that is the answer. |
| 34 |
|
| 35 |
> Have you read documentation? It is not about locations at all... my |
| 36 |
> problem is that it seems like that I have to use a new syntax from |
| 37 |
> systemd-udev when doing something in "/etc/systemd" but as said: I am |
| 38 |
> using sys-fs/udev, I don't care about systemd... why should I learn |
| 39 |
> systemd when I am only using udev? |
| 40 |
|
| 41 |
I haven't read the documentation, but I gather from the news item that |
| 42 |
a udev rules script is reading settings from a config file. If you |
| 43 |
want to use the fancy new magic config file, then obviously you need |
| 44 |
to use whatever syntax it operates under. If you just want to replace |
| 45 |
the udev rule, then I'd think that you could do that basically the |
| 46 |
same way you've always done it, unless the actual syntax of the rules |
| 47 |
is changing (which I suspect is unlikely). |
| 48 |
|
| 49 |
> Polynomical-C doesn't uses much patches... no, the magic is in the |
| 50 |
> ebuild. Upstream still supports the "old" usage... it is the Gentoo |
| 51 |
> ebuild which turns the package into systemd-udev... |
| 52 |
|
| 53 |
Bottom line is that upstream is doing it one way, and we have various |
| 54 |
people who want udev to behave differently in Gentoo. Take your pick, |
| 55 |
nobody is preventing polynomial-c from sticking his version in the |
| 56 |
main tree, and eudev is already there. |
| 57 |
|
| 58 |
Apparently there is an expectation that other packages may expect the |
| 59 |
file to be in the place upstream installs it. If that is the case |
| 60 |
then anybody wanting to use those packages would probably want to keep |
| 61 |
the files where upstream places them. However, I imagine that this |
| 62 |
will end up being a concern more for systemd and perhaps other |
| 63 |
packages that require it (Gnome, etc). |
| 64 |
|
| 65 |
> And that's what I meant when I said "give something 'back'": It should |
| 66 |
> be possible to create an ebuild for systemd and non-systemd users. Yes, |
| 67 |
> more maintenance is needed. But taking a package which was working fine |
| 68 |
> for non-systemd users and transform it into a systemd package isn't nice |
| 69 |
> and fair. |
| 70 |
|
| 71 |
I understand the frustration, but this really just reflects what |
| 72 |
upstream is doing. The old behavior has been forked back into |
| 73 |
packages like eudev, or polynomial-c's overlay. There is nothing |
| 74 |
wrong with using those packages, though it might cause issues if you |
| 75 |
use anything else which expects the new behavior out of udev. The |
| 76 |
trend is towards more vertical integration, so that might be more of a |
| 77 |
problem than it has been in the past. |
| 78 |
|
| 79 |
If the systemd folks had forked udev and called it something else I |
| 80 |
doubt there would be any complaining at all. Instead the upstream |
| 81 |
udev took off in a different direction. I know I've heard the word |
| 82 |
"takeover" used, but my understanding is that this isn't really what |
| 83 |
happened. Like Gnome the team (or whatever was left of it) just |
| 84 |
decided to move in a different direction. To them this stuff isn't |
| 85 |
controversial, and they don't feel like they have to give anything |
| 86 |
back, since they're the ones who gave it all in the first place. |
| 87 |
|
| 88 |
Rich |
Archives