-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
nixos/systemd-lib: don't fail on systemd.packages duplicates #77294
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/systemd-lib: don't fail on systemd.packages duplicates #77294
Conversation
In some cases like we've noticed in NixOS#76169, having duplicate packages in systemd.packages like ``` systemd.packages = [ gnome-shell gnome-shell gnome-session ]; ``` breaks. Here we use an associative array to ensure no duplicate paths when we symlink all the units listed in systemd.packages.
@@ -147,7 +147,13 @@ in rec { | |||
done | |||
|
|||
# Symlink all units provided listed in systemd.packages. | |||
for i in ${toString cfg.packages}; do | |||
packages="${toString cfg.packages}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would not toString (lib.unique cfg.packages)
work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lib.unique
is O(n^2), though not sure if that will realistically cause problems. Otherwise I'd say applying unique to systemd.packages
would be close to ideal (having a built in set type would be the best though :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't a built in set type be attrsOf
? I think it would be un-intuitive for systemd.packages
to have to be declared in anything other than a list, and because of systemPackages
.
On the topic of being O(n^2), there's a deprecated type that is basically this suggestion uniqList
.
When it comes to removing duplicates in bash versus lib.unique
, idk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't a built in set type be attrsOf?
Right, I was thinking more like a math set, ie. something like uniqList
. Agreed that it makes the most UX sense for it to be list.
When it comes to removing duplicates in bash versus lib.unique, idk.
Yep, I'm fine with both. Doing it through the option's apply with unique
is clean and will guard against any other uses, but O(n^2) isn't ideal so 🤷♂️
@GrahamcOfBorg test systemd gnome3 |
Systemd test was broken already https://hydra.nixos.org/job/nixos/trunk-combined/nixos.tests.systemd.x86_64-linux. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me at least. Tested together with #76985.
In some cases like we've noticed in #76169,
having duplicate packages in systemd.packages like
breaks.
Here we use an associative array to ensure no
duplicate paths when we symlink all the units listed
in systemd.packages.
Motivation for this change
A certain situation popped up where
gnome3
addsgnome-shell
andgnome-session
tosystemd.packages
, butgdm
also depends ongnome-shell
there.Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)