nordic-dev.net/nixpkgs
nordic-dev.net/nixpkgs
2
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-12-01 19:33:03 +00:00
Code Issues Packages Projects Releases Wiki Activity
c9ca370e32
nixpkgs/nixos/modules/rename.nix

34 lines
1.6 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 11:20:45 +00:00
{ lib, pkgs, ... }:
Fix style
2013-10-23 15:50:55 +00: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 14:26:48 +00: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 18:26:13 +00: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 16:05:50 +00: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 01:51:19 +00:00
/*
This file defines some renaming/removing options for backwards compatibility
nixos/neo4j: rename 'host' to 'listenAddress' More descriptive option name.
2015-12-23 22:58:42 +00: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 01:51:19 +00: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 16:05:50 +00: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 01:51:19 +00: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 16:05:50 +00: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 01:51:19 +00:00
# Completely removed modules
Mark services.firefox.syncserver.{user,group} as removed
2017-12-08 22:23:14 +00: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 20:26:33 +00: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 13:03:29 +00:00
(mkRemovedOptionModule [ "networking" "vpnc" ] "Use environment.etc.\"vpnc/service.conf\" instead.")
nixos/blcr: remove
2019-10-06 06:06:25 +00: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 16:33:51 +00: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 21:33:51 +00: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 17:46:15 +00:00
(mkRemovedOptionModule [ "services.fourStore" ] "The fourStore module has been removed")
(mkRemovedOptionModule [ "services.fourStoreEndpoint" ] "The fourStoreEndpoint 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 21:33:51 +00: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 01:51:19 +00: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 16:05:50 +00:00
}
Reference in New Issue Copy Permalink