Re: [Nix-dev] systemPackages vs. services.dbus.packages
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 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@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemPackages vs. services.dbus.packages
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 path, which can be compared as any string. I think such nub is missing in more places (I don't think it's yet done for build inputs and the like). Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemPackages vs. services.dbus.packages
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 math...@bluescreen303.nlwrote: 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 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@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemPackages vs. services.dbus.packages
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 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 math...@bluescreen303.nlwrote: 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 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@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemPackages vs. services.dbus.packages
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 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). 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. -- Кирилл Елагин On Tue, Apr 8, 2014 at 11:29 PM, Mathijs Kwik math...@bluescreen303.nl wrote: 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 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@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemPackages vs. services.dbus.packages
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 udevPackages. How exactly do you use that? I mean, there are _exactly two_ NixOS modules that add some packages to `dbus.packages` but do not add those same packages to `systemPackages`. % grep -Rl 'dbus\.packages' | xargs grep -L 'systemPackages' modules/services/x11/display-managers/lightdm.nix modules/services/x11/desktop-managers/e17.nix ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] systemPackages vs. services.dbus.packages
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 those packages are in services.dbus.packages,
and the latter is because they are in systemPackages and dbus modules adds
`/etc/dbus` to environment.pathsToLink.
That said, not all of the packages having their files in
`system-path/etc/dbus-1/system.d` also have them mentioned in
`/etc/dbus-1/system.conf`, that is, they are not listed in
services.dbus.packages. Those are (on my system) bluetooth, systemd
daemons, KDE stuff and PulseAudio.
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?
--
Кирилл Елагин
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
