Yes, we can nub them (to be precise, it makes sense to subtract `systemPackages` from `dbus.packages`), those lists contain package names, not derivations.
But, why not simply require all the packages that provide DBus services to be added to `dbus.packages`? That way we avoid duplication and have an explicit list of packages that have something to do with DBus (it might be useful in the future). -- Кирилл Елагин On Tue, Apr 8, 2014 at 11:29 PM, Mathijs Kwik <[email protected]>wrote: > Vladimír Čunát <[email protected]> writes: > > > On 04/07/2014 11:36 AM, Kirill Elagin wrote: > >> So, the question is: what is the purpose of having > >> services.dbus.packages if those configs are considered anyway due to > >> packages being in systemPackages? > > > > AFAIK there are cases where packages are not put into systemPackages, > > only to services.dbus.packages. (But that can't prevent the users or > > other options from independently adding the very same package to > > systemPackages.) > > I use that as much as possible. > There's really no need for a lot of packages to be in systemPackages or > in some user profile if they only provide a service and don't have lots > of often-used CLI tools. Same goes for udevPackages. > > However, wouldn't it be possible to uniq/nub these lists on evaluation? > It's perfectly functional/declarative, but I don't know if derivations > are comparable (for equality). > > > > > > > > Vlada > > > > > > _______________________________________________ > > nix-dev mailing list > > [email protected] > > http://lists.science.uu.nl/mailman/listinfo/nix-dev > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
