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

[Mathijs Kwik]

Kirill Elagin <kirelagin at gmail.com> writes:

> On Wed, Apr 9, 2014 at 12:24 AM, Mathijs Kwik <mathijs at bluescreen303.nl>wrote:
>
>> 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.
>>
>
> Because packages in `systemPackages` already have their dbus configs enabled
> just because they are in `systemPackages`. So there is no need to enable
> their dbus configs
> through `dbus.packages` logic (otherwise we get this duplication I was
> talking about).

Ah, I see config.system.path is in services.dbus.packages. That's a
pity. I was hoping individual packages were in there (as in packages =
cfg.packages + systemPackages). In that case making them uniq (or
removing the + systemPackages altogether) would do the trick.

>
>
>>  >
>> > 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.
>>
>
> I'm not sure what you are talking about.
> I thought we were talking about NixOS modules. Modules add themselves to
> `dbus.packages` just like to `systemPackages` conditionally, i.e. if they
> are enabled.
> You get those packages installed that correspond to enabled modules, that's
> how it works.

Not every module adds itself to systemPackages. To have it "installed", 
it's enough to (conditionally) add a package to dbus.packages or provide
a systemd.service 
Adding the package to systemPackages by default as well while it doesn't
really provide many often-used CLI commands only clobbers the system
environment (binaries show up in tab completion for each and every
user). I know lots of modules do this and it's understandable from a
traditional/non-nix point of view (just as putting config files in
/etc), but it's not necessary and better left to the system admin (and
users' profiles) in many cases.

But I now understand what you mean :)
Yes, modules should really just add themselves to dbus.packages, that
makes it very clear it provides dbus functionality, just like systemd
services are explicit. However, this will only work if the system path
isn't automatically added to dbus.packages as well. We can remove that,
but this has a lot of consequences. For modules, it's easy to
fix. However, people might have the expectation that adding stuff to
systemPackages themselves (in configuration.nix) will have it
"installed", including any dbus and udev stuff a package might provide.
Now they would have to add it to dbus.packages manually as well.
I think this is perfectly fine, as it's the case for systemd services as
well (If I add mysql to systemPackages without using the module I won't
get a systemd service), but it's potentially a breaking change for many
dbus services that get installed via desktop-environments.

The other option is to just use a linkDir-style derivation that builds 1
aggregated linkDir from dbus.packages. Like that, link-dereferencing
will make sure stuff will only be included once even if it's in
systemd.packages twice (even indirectly).



>
>
>
>>
>> >
>> >
>> > --
>> > Кирилл Елагин
>> >
>> >
>> > 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
>> >>
>>