Re: [Nix-dev] systemPackages vs. services.dbus.packages
Kirill Elagin writes: > On Tue, Apr 8, 2014 at 11:29 PM, Mathijs Kwik wrote: > >> 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`. Just put a package (like dunst) in dbus.packages without adding it to systemPackages. I'm not talking about modules here. On another system, I mkForce systemPackages, essentially removing stuff that gets added by default by modules and provide everything I do need manually. This can indeed be a bit cumbersome, but it really keeps the system profile clean. The fact that a system is running a database or webserver should not mean every user gets to see its binaries in their path. > > % 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
Re: [Nix-dev] systemPackages vs. services.dbus.packages
Kirill Elagin writes: > On Wed, Apr 9, 2014 at 12:24 AM, Mathijs Kwik wrote: > >> Kirill Elagin 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 > >wrote: >> > >> >> Vladimír Čunát 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/listinf
Re: [Nix-dev] systemPackages vs. services.dbus.packages
On Tue, Apr 8, 2014 at 11:29 PM, Mathijs Kwik wrote: > 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
Re: [Nix-dev] systemPackages vs. services.dbus.packages
On Wed, Apr 9, 2014 at 12:24 AM, Mathijs Kwik wrote: > Kirill Elagin 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 >wrote: > > > >> Vladimír Čunát 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 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 wrote: > >> Vladimír Čunát 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
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 wrote: > Vladimír Čunát 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 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
Vladimír Čunát 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/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.) 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