GNU bug report logs - #63787
udev-rules-service inoperable for some rules

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Felix Lechner <felix.lechner <at> lease-up.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#63787: closed (udev-rules-service inoperable for some rules)
Date: Thu, 06 Feb 2025 17:55:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 06 Feb 2025 09:54:32 -0800
with message-id <87jza39cx3.fsf <at> lease-up.com>
and subject line Underlying bug being worked on
has caused the debbugs.gnu.org bug report #63787,
regarding udev-rules-service inoperable for some rules
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
63787: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63787
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Felix Lechner <felix.lechner <at> lease-up.com>
To: bug-guix <at> gnu.org
Cc: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: udev-rules-service inoperable for some rules
Date: Mon, 29 May 2023 08:25:11 -0700

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

[Message part 3 (message/rfc822, inline)]

From: Felix Lechner <felix.lechner <at> lease-up.com>
To: 63787-done <at> debbugs.gnu.org
Cc: Liliana Marie Prikler <liliana.prikler <at> gmail.com>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Underlying bug being worked on
Date: Thu, 06 Feb 2025 09:54:32 -0800

Hi,

Another fix for the underlying Bug#63508 was proposed by Maxim
Cournoyer.

Closing this meta-bug.

Kind regards
Felix

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.