[Nix-dev] systemPackages vs. services.dbus.packages

[Mathijs Kwik]

Kirill Elagin <kirelagin at 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 dbus service.

>
> 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).

Adding packages to dbus.packages will cause them to be installed.
I do not want each and every dbus-providing package to get installed and
activated.




>
>
> --
> Кирилл Елагин
>
>
> On Tue, Apr 8, 2014 at 11:29 PM, Mathijs Kwik <mathijs at bluescreen303.nl>wrote:
>
>> Vladimír Čunát <vcunat at 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 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
>> > nix-dev at lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>