Vladimír Čunát vcu...@gmail.com 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
On 04/08/2014 09:29 PM, Mathijs Kwik wrote:
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).
They are comparable, as what you get in hand is practically the output
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
Kirill Elagin kirela...@gmail.com writes:
Yes, we can nub them (to be precise, it makes sense to subtract
`systemPackages` from `dbus.packages`), those lists contain
package names, not derivations.
Why should systemPackages be subtracted?
There are packages that I want in my path _and_ as a
On Wed, Apr 9, 2014 at 12:24 AM, Mathijs Kwik math...@bluescreen303.nlwrote:
Kirill Elagin kirela...@gmail.com writes:
Yes, we can nub them (to be precise, it makes sense to subtract
`systemPackages` from `dbus.packages`), those lists contain
package names, not derivations.
Why should
On Tue, Apr 8, 2014 at 11:29 PM, Mathijs Kwik math...@bluescreen303.nlwrote:
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
Hi all,
I've just noticed that some of system packages have their DBus config
sourced twice.
Their `etc/dbus-1/system.d/` directories are both explicitly listed in
`/etc/dbus-1/system.conf` and are symlinked from
`/nix/store/${hash}-system-path/etc/dbus-1/system.d`.
The former happens because
