(address . bug-guix@gnu.org)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
CAFHYt55059XYmkR_UFw0FjHg5iHcw8-=O=hxSjt9-hgLMgaxKg@mail.gmail.com
Hi,
A brief thread from guix-devel about trying to use MAC-based names for
network interfaces [1] shall be incorporated herein by reference.
On Wed, May 17, 2023 at 6:14?PM Felix Lechner
<felix.lechner@lease-up.com> wrote:
Toggle quote (4 lines)
>
> 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.
Toggle quote (7 lines)
> (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.
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.
[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.
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.
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