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