cafkafk/nixpkgs
cafkafk/nixpkgs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
nixpkgs/nixos/modules/rename.nix

55 lines
2.9 KiB
Nix
Raw Normal View History

cups service: Automatically detect Gutenprint in drivers Additional CUPS drivers can be added via "services.printing.drivers" but Gutenprint was an exception. It was possible to add a Gutenprint derivation to that list and it would work at first but unlike the other drivers Gutenprint requires a script to be run after each update or any attempt to print something would simply fail and an error would show up in the jobs queue (http://localhost:631/jobs/): "The PPD version (5.2.11) is not compatible with Gutenprint 5.2.13. Please run `/nix/store/7762kpyhfkcgmr3q81v1bbyy0bjhym80-gutenprint-5.2.13/sbin/cups-genppdupdate' as administrator." This is due to state in "/var/lib/cups/ppd" and one would need to run "/nix/store/.../bin/cups-genppdupdate -p /var/lib/cups/ppd" manually. The alternative was to enable the following option: "services.printing.gutenprint" but this had two disadvantages: 1) It is an exception that one could be unaware of or that could potentially cause some confusion. 2) One couldn't use a customized Gutenprint derivation in "services.printing.drivers" but would instead have to overwrite "pkgs.gutenprint". This new approach simply detects a Gutenprint derivation in "services.printing.gutenprint" by checking if the meta set of a derivation contains "isGutenprint = true". Therefore no special exception for Gutenprint would be required and it could easily be applied to other drivers if they would require such a script to be run.
2017-08-20 13:20:45 +02:00
{ lib, pkgs, ... }:
Fix style
2013-10-23 17:50:55 +02:00
Rewrite ‘with pkgs.lib’ -> ‘with lib’ Using pkgs.lib on the spine of module evaluation is problematic because the pkgs argument depends on the result of module evaluation. To prevent an infinite recursion, pkgs and some of the modules are evaluated twice, which is inefficient. Using ‘with lib’ prevents this problem.
2014-04-14 16:26:48 +02:00
with lib;
Add a renaming module. This module introduce the rename function to fetch definitions of oldest options and to add them inside the new option. Properties are still valid and will not be affected by the renaming. e.g: with: rename alias "foo.bar" to "baz.quz" and with the following module: { foo.bar = (mkOverride 10 {}) 42; baz.quz = 21; } the result of baz.quz would be 42 because the priority is still working after the renaming. svn path=/nixos/trunk/; revision=17484
2009-09-28 20:26:13 +02:00
Factor out option renaming Option aliases/deprecations can now be declared in any NixOS module, not just in nixos/modules/rename.nix. This is more modular (since it allows for example grub-related aliases to be declared in the grub module), and allows aliases outside of NixOS (e.g. in NixOps modules). The syntax is a bit funky. Ideally we'd have something like: options = { foo.bar.newOption = mkOption { ... }; foo.bar.oldOption = mkAliasOption [ "foo" "bar" "newOption" ]; }; but that's not possible because options cannot define values in *other* options - you need to have a "config" for that. So instead we have functions that return a *module*: mkRemovedOptionModule, mkRenamedOptionModule and mkAliasOptionModule. These can be used via "imports", e.g. imports = [ (mkAliasOptionModule [ "foo" "bar" "oldOption" ] [ "foo" "bar" "newOption" ]); ]; As an added bonus, deprecation warnings now show the file name of the offending module. Fixes #10385.
2015-10-14 18:05:50 +02:00
{
imports = [
nixos/treewide: Move rename.nix imports to their respective modules A centralized list for these renames is not good because: - It breaks disabledModules for modules that have a rename defined - Adding/removing renames for a module means having to find them in the central file - Merge conflicts due to multiple people editing the central file
2019-12-10 02:51:19 +01:00
/*
This file defines some renaming/removing options for backwards compatibility
nixos/neo4j: rename 'host' to 'listenAddress' More descriptive option name.
2015-12-23 23:58:42 +01:00
nixos/treewide: Move rename.nix imports to their respective modules A centralized list for these renames is not good because: - It breaks disabledModules for modules that have a rename defined - Adding/removing renames for a module means having to find them in the central file - Merge conflicts due to multiple people editing the central file
2019-12-10 02:51:19 +01:00
It should ONLY be used when the relevant module can't define these imports
itself, such as when the module was removed completely.
See https://github.com/NixOS/nixpkgs/pull/61570 for explanation
*/
Factor out option renaming Option aliases/deprecations can now be declared in any NixOS module, not just in nixos/modules/rename.nix. This is more modular (since it allows for example grub-related aliases to be declared in the grub module), and allows aliases outside of NixOS (e.g. in NixOps modules). The syntax is a bit funky. Ideally we'd have something like: options = { foo.bar.newOption = mkOption { ... }; foo.bar.oldOption = mkAliasOption [ "foo" "bar" "newOption" ]; }; but that's not possible because options cannot define values in *other* options - you need to have a "config" for that. So instead we have functions that return a *module*: mkRemovedOptionModule, mkRenamedOptionModule and mkAliasOptionModule. These can be used via "imports", e.g. imports = [ (mkAliasOptionModule [ "foo" "bar" "oldOption" ] [ "foo" "bar" "newOption" ]); ]; As an added bonus, deprecation warnings now show the file name of the offending module. Fixes #10385.
2015-10-14 18:05:50 +02:00
nixos/treewide: Move rename.nix imports to their respective modules A centralized list for these renames is not good because: - It breaks disabledModules for modules that have a rename defined - Adding/removing renames for a module means having to find them in the central file - Merge conflicts due to multiple people editing the central file
2019-12-10 02:51:19 +01:00
# This alias module can't be where _module.check is defined because it would
# be added to submodules as well there
Factor out option renaming Option aliases/deprecations can now be declared in any NixOS module, not just in nixos/modules/rename.nix. This is more modular (since it allows for example grub-related aliases to be declared in the grub module), and allows aliases outside of NixOS (e.g. in NixOps modules). The syntax is a bit funky. Ideally we'd have something like: options = { foo.bar.newOption = mkOption { ... }; foo.bar.oldOption = mkAliasOption [ "foo" "bar" "newOption" ]; }; but that's not possible because options cannot define values in *other* options - you need to have a "config" for that. So instead we have functions that return a *module*: mkRemovedOptionModule, mkRenamedOptionModule and mkAliasOptionModule. These can be used via "imports", e.g. imports = [ (mkAliasOptionModule [ "foo" "bar" "oldOption" ] [ "foo" "bar" "newOption" ]); ]; As an added bonus, deprecation warnings now show the file name of the offending module. Fixes #10385.
2015-10-14 18:05:50 +02:00
(mkAliasOptionModule [ "environment" "checkConfigurationOptions" ] [ "_module" "check" ])
nixos/treewide: Move rename.nix imports to their respective modules A centralized list for these renames is not good because: - It breaks disabledModules for modules that have a rename defined - Adding/removing renames for a module means having to find them in the central file - Merge conflicts due to multiple people editing the central file
2019-12-10 02:51:19 +01:00
# Completely removed modules
Mark services.firefox.syncserver.{user,group} as removed
2017-12-08 23:23:14 +01:00
(mkRemovedOptionModule [ "services" "firefox" "syncserver" "user" ] "")
(mkRemovedOptionModule [ "services" "firefox" "syncserver" "group" ] "")
winstone: drop package and service Close #56294 Upstream package is unmaintained for years and nixpkgs provides alternatives
2019-05-14 22:26:33 +02:00
(mkRemovedOptionModule [ "services" "winstone" ] "The corresponding package was removed from nixpkgs.")
networking.vpnc: remove option This PR is part of the networking.* namespace cleanup. The Cisco VPN module is currently of limited value since it just creates config files but does not manage services. The same functionality can be achieved by using _environment.etc_ instead. It would be a different situation if we had a full service module. So if you are annoyed by this change, please consider write a more featureful module and put its options unter _services.networking.vpnc_. Note that this change removes options for *Cisco VPN*, not *networkmanager-vpn*.
2019-11-24 14:03:29 +01:00
(mkRemovedOptionModule [ "networking" "vpnc" ] "Use environment.etc.\"vpnc/service.conf\" instead.")
nixos/blcr: remove
2019-10-06 08:06:25 +02:00
(mkRemovedOptionModule [ "environment.blcr.enable" ] "The BLCR module has been removed")
nixos/beegfs: remove module packages are marked as broken for quite some time.
2019-11-24 17:33:51 +01:00
(mkRemovedOptionModule [ "services.beegfsEnable" ] "The BeeGFS module has been removed")
(mkRemovedOptionModule [ "services.beegfs" ] "The BeeGFS module has been removed")
osquery: remove osquery was marked as broken since April. If somebody steps up to fix it, we can always revive it from the histroy, but there's not much value in shipping completely broken things in current master. cc @ma27
2019-11-24 22:33:51 +01:00
(mkRemovedOptionModule [ "services.osquery" ] "The osquery module has been removed")
rdf4store: throw removal messages Addition to #74214 I forgot to add aliases for package and modules after removal
2019-12-21 18:46:15 +01:00
(mkRemovedOptionModule [ "services.fourStore" ] "The fourStore module has been removed")
(mkRemovedOptionModule [ "services.fourStoreEndpoint" ] "The fourStoreEndpoint module has been removed")
way-cooler: Remove As of 2020-01-09, way-cooler is officially dead: http://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html hence, remove the package and the module. Signed-off-by: Matthias Beyer <mail@beyermatthias.de> docs/release-notes: remove way-cooler way-cooler: show warnings about removal Apply suggestions from code review Co-Authored-By: worldofpeace <worldofpeace@protonmail.ch> way-cooler: add suggestion by @Infinisil
2020-01-13 15:59:11 +01:00
(mkRemovedOptionModule [ "programs" "way-cooler" ] ("way-cooler is abandoned by its author: " +
"https://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html"))
nixos/multitouch: remove On numerous occasions I have seen users mistake this module as libinput because it being called "multitouch" and them being unaware that the actually module they want is libinput. They then run into several decrepit bugs due to the completely out-of-date nature of the underlying package. The underlying package hasn't been changed to an up-to-date fork in a period of 8 years. I don't consider this to be production quality. However, I'm not opposed for the module being readded to NixOS with new packaging, and a better name.
2020-01-19 01:57:10 +01:00
(mkRemovedOptionModule [ "services" "xserver" "multitouch" ] ''
services.xserver.multitouch (which uses xf86_input_mtrack) has been removed
as the underlying package isn't being maintained. Working alternatives are
libinput and synaptics.
'')
nixos/display-managers/auto: remove This module allows root autoLogin, so we would break that for users, but they shouldn't be using it anyways. This gives the impression like auto is some special display manager, when it's just lightdm and special pam rules to allow root autoLogin. It was created for NixOS's testing so I believe this is where it belongs.
2020-01-26 23:41:19 +01:00
(mkRemovedOptionModule [ "services" "xserver" "displayManager" "auto" ] ''
The services.xserver.displayManager.auto module has been removed
because it was only intended for use in internal NixOS tests, and gave the
false impression of it being a special display manager when it's actually
LightDM. Please use the services.xserver.displayManager.lightdm.autoLogin options
instead, or any other display manager in NixOS as they all support auto-login.
'')
nixos/dnscrypt-proxy2: init This removes the original dnscrypt-proxy module as well. Co-authored-by: Atemu <atemu.main@gmail.com> Co-authored-by: Silvan Mosberger <contact@infinisil.com> Co-authored-by: ryneeverett <ryneeverett@gmail.com> Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>
2018-10-12 23:38:54 +02:00
(mkRemovedOptionModule [ "services" "dnscrypt-proxy" ] "Use services.dnscrypt-proxy2 instead")
nixos/brightnessctl: Remove the module Due to the support of the systemd-logind API the udev rules aren't required anymore which renders this module useless [0]. Note: brightnessctl should now require a working D-Bus setup and a valid local logind session for this to work. [0]: https://github.com/NixOS/nixpkgs/pull/79663
2020-02-10 23:10:53 +01:00
(mkRemovedOptionModule ["hardware" "brightnessctl" ] ''
The brightnessctl module was removed because newer versions of
brightnessctl don't require the udev rules anymore (they can use the
systemd-logind API). Instead of using the module you can now
simply add the brightnessctl package to environment.systemPackages.
'')
osquery: remove osquery was marked as broken since April. If somebody steps up to fix it, we can always revive it from the histroy, but there's not much value in shipping completely broken things in current master. cc @ma27
2019-11-24 22:33:51 +01:00
nixos/treewide: Move rename.nix imports to their respective modules A centralized list for these renames is not good because: - It breaks disabledModules for modules that have a rename defined - Adding/removing renames for a module means having to find them in the central file - Merge conflicts due to multiple people editing the central file
2019-12-10 02:51:19 +01:00
# Do NOT add any option renames here, see top of the file
];
Factor out option renaming Option aliases/deprecations can now be declared in any NixOS module, not just in nixos/modules/rename.nix. This is more modular (since it allows for example grub-related aliases to be declared in the grub module), and allows aliases outside of NixOS (e.g. in NixOps modules). The syntax is a bit funky. Ideally we'd have something like: options = { foo.bar.newOption = mkOption { ... }; foo.bar.oldOption = mkAliasOption [ "foo" "bar" "newOption" ]; }; but that's not possible because options cannot define values in *other* options - you need to have a "config" for that. So instead we have functions that return a *module*: mkRemovedOptionModule, mkRenamedOptionModule and mkAliasOptionModule. These can be used via "imports", e.g. imports = [ (mkAliasOptionModule [ "foo" "bar" "oldOption" ] [ "foo" "bar" "newOption" ]); ]; As an added bonus, deprecation warnings now show the file name of the offending module. Fixes #10385.
2015-10-14 18:05:50 +02:00
}
Reference in a new issue Copy permalink