Hi, A brief thread from guix-devel about trying to use MAC-based names for network interfaces [1] shall be incorporated herein by reference.
[1] https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00192.html On Wed, May 17, 2023 at 6:14 PM Felix Lechner <felix.lech...@lease-up.com> wrote: > > In a concession to Liliana's opposition, I retitled the bug to > sidestep the question of the MAC-based names as a default setting. It was not enough of a concession. In Guix, many custom rules like the following—namely those that use values determined by udevadm—are inoperable. > (udev-rules-service 'net-name-mac > (udev-rule > "79-net-name-mac.rules" > " > SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\" > "))) The issue is that udevadm looks in the installation folder for udev rules. In standard distros, that works fine because the installation folder and the runtime folder are the same. Unfortunately, that is not so for Guix. The installation folder is in the store. The way I understand our strategy in Guix, we construct another, aggregate folder with links to rules in /etc/udev/rules.d. (That location also happens to be the installation directory for many traditional distros.) I proposed a local patch that causes udevadm to look in that folder instead. [2] It replaces one line in the source code. [2] https://issues.guix.gnu.org/63508#12 Liliana, who kindly reviewed my patch, disagreed with that solution. For reasons I do not fully understand, she prefers a more generalized solution via an environmental variable called EUDEV_RULES_DIRECTORY. [3] As far as I can tell, that variable is not provided by upstream. It was invented by a custom patch to Guix [4] and currently does not seem to work all the way. [3] https://issues.guix.gnu.org/63508#6 [4] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/eudev-rules-directory.patch Liliana insists on improving the environment variable EUDEV_RULES_DIRECTORY, while I have several issues with that. For starters, my substitution is simpler. It is also a common packaging strategy in Guix. (I furthermore cannot envision setting the variable to any value other than /etc/udev/rules.d, although maybe the flexibility comes in handy one day.) Mainly, however, I believe that her patch goes beyond the typical packaging activity. By implementing a new feature, the patch for EUDEV_RULES_DIRECTORY should really be sent upstream. I do not know whether that's already happened, but I am not convinced upstream would accept it. In the latest 3.2.12 release, which does not work without further modifications in Guix, the upstream developers added a command-line option called '--root' to udevadm [5] that offers another solution to setting the runtime path. Unfortunately, that option does not change the default, which is the issue in this bug. [5] https://github.com/eudev-project/eudev/blob/2703baf55615b7554fb67c4f1c241f057f8c0a79/man/udevadm.8#L378C2-L380 Finally, programming styles also differ. I have philosophical objections to the use of pointer arithmetic, although the upstream code may have some of that, too. With the discussion at an impasse, I am not sure how to proceed. Eudev, which is an essential part of any modern Linux operating system, is not working properly in Guix. Liliana challenged me to "file a formal complaint." [6] I do not know what that means and now filed this bug in hope of finding an acceptable way forward. Maybe it is easier to discuss the reasoning for one fix or another when the arguments for and against are not separated by multiple versions of competing inline patches. [6] https://issues.guix.gnu.org/63508#22 For the success of any group, it is essential that problems are being solved. Perhaps someone with an independent perspective would be so kind to comment and help bring this bug one step closer to being closed. Thanks! Kind regards, Felix cc: Liliana
