By analyzing the blame information on this pull request, we identified @edolstra, @urkud and @aszlig to be potential reviewers

I've just noticed that #10646 was caused by this, too.

@ctheune could this also be the reason for your problems in #12833 ?

Thanks for the headsup, I'll check that, but I don't think so. @abbradar: did you get rules applied after a switch at all?

Yes, and it also doesn't look to me this would fix your problem. FWIW, I have thought that relative paths won't work in udev altogether (same as in systemd), and PATH is set not for PROGRAM calls, but for sh calls in PROGRAM, like:

PROGRAM="/bin/sh -c 'fc-get-disk-alias %k'"

This will actually make some rules lower priority, such as:

    # Name network interfaces after their MAC address.
    services.udev.extraRules =
      ''
        SUBSYSTEM!="net", GOTO="my_end"
        IMPORT{builtin}="net_id"
        KERNEL=="vnet*", GOTO="my_end"
        NAME=="", ENV{ID_NET_NAME_MAC}!="", NAME="$env{ID_NET_NAME_MAC}"
        LABEL="my_end"
      '';

Because of the NAME=="" guard, it won't execute since systemd's 80-net-setup-link.rules has

NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"

Hm, I see the problem. What do you think of replacing extraRules with extraPreRules and extraPostRules? This would prevent further confusion like mine and in #10646.

I went ahead and implemented the proposed idea. In this incarnation I remove udev.extraRules completely to prevent further confusion -- is this acceptable?

I don't know enough about udev to check over this. However, I might suggest using nixos/modules/rename.nix so existing uses of udev.extraRules will work for some time.

Yeah, indeed -- removing extraRules completely might be too harsh now. I've updated the patch.

I think this is good to go and should remove much of the confusion around udev rules not working, but I want @edolstra comment as someone who's more knowledgeable on udev. What do you think? tl;dr: this splits out extraRules option into two separate ones for pre- and post-rules -- I expect that people who know what they are doing would now have a place to write post-rules and people who just want some god-damned rule found for their device to work would try both options and get it working one way or another.

Another possibility is to do your original proposal, and simply document the changed semantics in the release notes. For instance, in the example I posted, the fix is pretty easy (just remove the NAME==... check).

Hm, well -- truth be told I haven't seen much udev rules, so if pre-rules are not that much of a common case (the only one I've seen is your example), I think leaving just one option is better. Okay, let's do this! I'll add corresponding entries to the changelog.

The original patch is back, I've also added a changelog entry for it. Should be good now -- I'll merge this in few days unless we discover any problems with this.