Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/udev: use udev rules from $lib if present, otherwise $out #93006

Closed
wants to merge 1 commit into from

Conversation

flokli
Copy link
Contributor

@flokli flokli commented Jul 12, 2020

$bin is meant for executable binaries, not udev rules, and
./{lib,etc}/udev/rules.d also doesn't suggest for these to be in
$bin.

Motivation for this change

I was packaging something with multiple outputs and both $bin and $lib outputs, and was wondering myself a lot on why they weren't picked up.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

`$bin` is meant for executable binaries, not udev rules, and
`./{lib,etc}/udev/rules.d` also doesn't suggest for these to be in
`$bin`.
@flokli
Copy link
Contributor Author

flokli commented Jul 12, 2020

I'd also be fine with this being $out all the time, but $bin clearly sounds wrong.

@flokli
Copy link
Contributor Author

flokli commented Jul 12, 2020

Also cc @ttuegel due to faf0d3e

Copy link
Contributor

@Valodim Valodim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like it might be a reasonable change. Some considerations:

  • If we want to separate out udev rules, perhaps a udev output makes sense? I just checked and moolticute actually does this already, and seabreeze used to. The only reason to call this "lib" is FHS heritage, iinm, and a udev output feels more "typesafe", in a way.
  • On the other hand, I suspect udev rules commonly trigger binaries, which will then be in their bin output, so we will anyways have that dependency in the majority of cases.

Either way, before merging this we need to make sure this doesn't break any packaged rules. Did you check that there is no derivation (besides bluez-qt) that packages its udev files into bin? I spotted libmtp as a candidate with nix-locate, at least.

@@ -190,7 +190,7 @@ in
<filename><replaceable>pkg</replaceable>/lib/udev/rules.d</filename>
will be included.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This documentation should definitely mention that this applies to files from the lib or default output.

<listitem>
<para>
In the case of multiple output derivations, the <link linkend="opt-services.udev.packages">services.udev.packages</link> option
now takes udev rules from <literal>lib</literal>, not <literal>bin</literal>.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
now takes udev rules from <literal>lib</literal>, not <literal>bin</literal>.
now takes udev rules from the <literal>lib</literal>, <literal>out</literal>, or default output (in that order), not <literal>bin</literal>.

@ttuegel ttuegel requested review from ttuegel and removed request for ttuegel July 13, 2020 14:43
@flokli
Copy link
Contributor Author

flokli commented Jul 13, 2020

Hm, a udev output might make sense, but do we then also want a lib.getUdev with fallback logic via lib, out and the default output?

Also, the same might apply for systemd.tmpfiles.packages and lib.getTmpfiles (once added) - maybe it's easier to put everything in $lib.

systemd.packages (and which outputs systemd units are picked from) also is somewhat inconsistent with what we plan here - any thoughts?

@flokli flokli added this to To Do in systemd via automation Jul 13, 2020
@flokli
Copy link
Contributor Author

flokli commented Jul 13, 2020

In a discussion on #nixos, it was proposed to fail building the nixos configuration if you try to assign a package (output) to services.udev.packages that doesn't expose anything in {etc,lib}/udev/rules.d (and handle tmpfiles and systemd.packages in a similar fashion). That way, moving around outputs to a more consistent layout would become less scary, as we don't accidentially silently miss and drop units or udev rules.

@flokli
Copy link
Contributor Author

flokli commented Sep 14, 2020

I'm still not sure which output to best put this into, and it certainly won't happen in 20.09 either. Let's close this for the time being.

@flokli flokli closed this Sep 14, 2020
@arianvp arianvp moved this from To Do to Done in systemd Dec 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
systemd
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

5 participants