diff options
Diffstat (limited to 'nixpkgs/doc')
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/idris.section.md | 18 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/java.xml | 9 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/python.section.md | 1 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/qt.xml | 225 | ||||
| -rw-r--r-- | nixpkgs/doc/languages-frameworks/vim.section.md | 168 | ||||
| -rw-r--r-- | nixpkgs/doc/package-specific-user-notes.xml | 51 | ||||
| -rw-r--r-- | nixpkgs/doc/stdenv.xml | 12 |
7 files changed, 330 insertions, 154 deletions
diff --git a/nixpkgs/doc/languages-frameworks/idris.section.md b/nixpkgs/doc/languages-frameworks/idris.section.md index 3025172b5c98..e88015f08e3f 100644 --- a/nixpkgs/doc/languages-frameworks/idris.section.md +++ b/nixpkgs/doc/languages-frameworks/idris.section.md @@ -124,3 +124,21 @@ in another file (say `default.nix`) to be able to build it with ``` $ nix-build -A yaml ``` + +## Passing options to `idris` commands + +The `build-idris-package` function provides also optional input values to set additional options for the used `idris` commands. + +Specifically, you can set `idrisBuildOptions`, `idrisTestOptions`, `idrisInstallOptions` and `idrisDocOptions` to provide additional options to the `idris` command respectively when building, testing, installing and generating docs for your package. + +For example you could set + +``` +build-idris-package { + idrisBuildOptions = [ "--log" "1" "--verbose" ] + + ... +} +``` + +to require verbose output during `idris` build phase. diff --git a/nixpkgs/doc/languages-frameworks/java.xml b/nixpkgs/doc/languages-frameworks/java.xml index 287f63e685c4..68a1a097984d 100644 --- a/nixpkgs/doc/languages-frameworks/java.xml +++ b/nixpkgs/doc/languages-frameworks/java.xml @@ -10,7 +10,7 @@ stdenv.mkDerivation { name = "..."; src = fetchurl { ... }; - buildInputs = [ jdk ant ]; + nativeBuildInputs = [ jdk ant ]; buildPhase = "ant"; } @@ -30,7 +30,8 @@ stdenv.mkDerivation { <filename>foo.jar</filename> in its <filename>share/java</filename> directory, and another package declares the attribute <programlisting> -buildInputs = [ jdk libfoo ]; +buildInputs = [ libfoo ]; +nativeBuildInputs = [ jdk ]; </programlisting> then <envar>CLASSPATH</envar> will be set to <filename>/nix/store/...-libfoo/share/java/foo.jar</filename>. @@ -46,7 +47,7 @@ buildInputs = [ jdk libfoo ]; script to run it using the OpenJRE. You can use <literal>makeWrapper</literal> for this: <programlisting> -buildInputs = [ makeWrapper ]; +nativeBuildInputs = [ makeWrapper ]; installPhase = '' @@ -76,7 +77,7 @@ installPhase = It is possible to use a different Java compiler than <command>javac</command> from the OpenJDK. For instance, to use the GNU Java Compiler: <programlisting> -buildInputs = [ gcj ant ]; +nativeBuildInputs = [ gcj ant ]; </programlisting> Here, Ant will automatically use <command>gij</command> (the GNU Java Runtime) instead of the OpenJRE. diff --git a/nixpkgs/doc/languages-frameworks/python.section.md b/nixpkgs/doc/languages-frameworks/python.section.md index 77b387dd3025..4963c97a6c9a 100644 --- a/nixpkgs/doc/languages-frameworks/python.section.md +++ b/nixpkgs/doc/languages-frameworks/python.section.md @@ -603,6 +603,7 @@ All parameters from `stdenv.mkDerivation` function are still supported. The foll * `preShellHook`: Hook to execute commands before `shellHook`. * `postShellHook`: Hook to execute commands after `shellHook`. * `removeBinByteCode ? true`: Remove bytecode from `/bin`. Bytecode is only created when the filenames end with `.py`. +* `setupPyGlobalFlags ? []`: List of flags passed to `setup.py` command. * `setupPyBuildFlags ? []`: List of flags passed to `setup.py build_ext` command. The `stdenv.mkDerivation` function accepts various parameters for describing build inputs (see "Specifying dependencies"). The following are of special diff --git a/nixpkgs/doc/languages-frameworks/qt.xml b/nixpkgs/doc/languages-frameworks/qt.xml index b9b605b81da1..3332ce8c06e4 100644 --- a/nixpkgs/doc/languages-frameworks/qt.xml +++ b/nixpkgs/doc/languages-frameworks/qt.xml @@ -4,71 +4,182 @@ <title>Qt</title> <para> - Qt is a comprehensive desktop and mobile application development toolkit for - C++. Legacy support is available for Qt 3 and Qt 4, but all current - development uses Qt 5. The Qt 5 packages in Nixpkgs are updated frequently to - take advantage of new features, but older versions are typically retained - until their support window ends. The most important consideration in - packaging Qt-based software is ensuring that each package and all its - dependencies use the same version of Qt 5; this consideration motivates most - of the tools described below. + This section describes the differences between Nix expressions for Qt + libraries and applications and Nix expressions for other C++ software. Some + knowledge of the latter is assumed. There are primarily two problems which + the Qt infrastructure is designed to address: ensuring consistent versioning + of all dependencies and finding dependencies at runtime. </para> - <section xml:id="ssec-qt-libraries"> - <title>Packaging Libraries for Nixpkgs</title> + <example xml:id='qt-default-nix'> + <title>Nix expression for a Qt package (<filename>default.nix</filename>)</title> + <programlisting> +{ mkDerivation, lib, qtbase }: <co xml:id='qt-default-nix-co-1' /> - <para> - Whenever possible, libraries that use Qt 5 should be built with each - available version. Packages providing libraries should be added to the - top-level function <varname>mkLibsForQt5</varname>, which is used to build a - set of libraries for every Qt 5 version. A special - <varname>callPackage</varname> function is used in this scope to ensure that - the entire dependency tree uses the same Qt 5 version. Import dependencies - unqualified, i.e., <literal>qtbase</literal> not - <literal>qt5.qtbase</literal>. <emphasis>Do not</emphasis> import a package - set such as <literal>qt5</literal> or <literal>libsForQt5</literal>. - </para> +mkDerivation { <co xml:id='qt-default-nix-co-2' /> + pname = "myapp"; + version = "1.0"; - <para> - If a library does not support a particular version of Qt 5, it is best to - mark it as broken by setting its <literal>meta.broken</literal> attribute. A - package may be marked broken for certain versions by testing the - <literal>qtbase.version</literal> attribute, which will always give the - current Qt 5 version. - </para> - </section> + buildInputs = [ qtbase ]; <co xml:id='qt-default-nix-co-3' /> +} + </programlisting> + </example> - <section xml:id="ssec-qt-applications"> - <title>Packaging Applications for Nixpkgs</title> + <calloutlist> + <callout arearefs='qt-default-nix-co-1'> + <para> + Import <literal>mkDerivation</literal> and Qt (such as + <literal>qtbase</literal> modules directly. <emphasis>Do not</emphasis> + import Qt package sets; the Qt versions of dependencies may not be + coherent, causing build and runtime failures. + </para> + </callout> + <callout arearefs='qt-default-nix-co-2'> + <para> + Use <literal>mkDerivation</literal> instead of + <literal>stdenv.mkDerivation</literal>. <literal>mkDerivation</literal> + is a wrapper around <literal>stdenv.mkDerivation</literal> which + applies some Qt-specific settings. + This deriver accepts the same arguments as + <literal>stdenv.mkDerivation</literal>; refer to + <xref linkend='chap-stdenv' /> for details. + </para> + <para> + To use another deriver instead of + <literal>stdenv.mkDerivation</literal>, use + <literal>mkDerivationWith</literal>: +<programlisting> +mkDerivationWith myDeriver { + # ... +} +</programlisting> + If you cannot use <literal>mkDerivationWith</literal>, please refer to + <xref linkend='qt-runtime-dependencies' />. + </para> + </callout> + <callout arearefs='qt-default-nix-co-3'> + <para> + <literal>mkDerivation</literal> accepts the same arguments as + <literal>stdenv.mkDerivation</literal>, such as + <literal>buildInputs</literal>. + </para> + </callout> + </calloutlist> - <para> - Call your application expression using - <literal>libsForQt5.callPackage</literal> instead of - <literal>callPackage</literal>. Import dependencies unqualified, i.e., - <literal>qtbase</literal> not <literal>qt5.qtbase</literal>. <emphasis>Do - not</emphasis> import a package set such as <literal>qt5</literal> or - <literal>libsForQt5</literal>. - </para> + <formalpara xml:id='qt-runtime-dependencies'> + <title>Locating runtime dependencies</title> + <para> + Qt applications need to be wrapped to find runtime dependencies. If you + cannot use <literal>mkDerivation</literal> or + <literal>mkDerivationWith</literal> above, include + <literal>wrapQtAppsHook</literal> in <literal>nativeBuildInputs</literal>: +<programlisting> +stdenv.mkDerivation { + # ... - <para> - Qt 5 maintains strict backward compatibility, so it is generally best to - build an application package against the latest version using the - <varname>libsForQt5</varname> library set. In case a package does not build - with the latest Qt version, it is possible to pick a set pinned to a - particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that - is the latest version the package supports. If a package must be pinned to - an older Qt version, be sure to file a bug upstream; because Qt is strictly - backwards-compatible, any incompatibility is by definition a bug in the - application. - </para> + nativeBuildInputs = [ wrapQtAppsHook ]; +} +</programlisting> + </para> + </formalpara> + + <para> + Entries added to <literal>qtWrapperArgs</literal> are used to modify the + wrappers created by <literal>wrapQtAppsHook</literal>. The entries are + passed as arguments to <xref linkend='fun-wrapProgram' />. +<programlisting> +mkDerivation { + # ... + + qtWrapperArgs = [ ''--prefix PATH : /path/to/bin'' ]; +} +</programlisting> + </para> + + <para> + Set <literal>dontWrapQtApps</literal> to stop applications from being + wrapped automatically. It is required to wrap applications manually with + <literal>wrapQtApp</literal>, using the syntax of + <xref linkend='fun-wrapProgram' />: +<programlisting> +mkDerivation { + # ... + dontWrapQtApps = true; + preFixup = '' + wrapQtApp "$out/bin/myapp" --prefix PATH : /path/to/bin + ''; +} +</programlisting> + </para> + + <note> <para> - When testing applications in Nixpkgs, it is a common practice to build the - package with <literal>nix-build</literal> and run it using the created - symbolic link. This will not work with Qt applications, however, because - they have many hard runtime requirements that can only be guaranteed if the - package is actually installed. To test a Qt application, install it with - <literal>nix-env</literal> or run it inside <literal>nix-shell</literal>. + <literal>wrapQtAppsHook</literal> ignores files that are non-ELF executables. + This means that scripts won't be automatically wrapped so you'll need to manually + wrap them as previously mentioned. An example of when you'd always need to do this + is with Python applications that use PyQT. </para> - </section> + </note> + + <para> + Libraries are built with every available version of Qt. Use the <literal>meta.broken</literal> + attribute to disable the package for unsupported Qt versions: +<programlisting> +mkDerivation { + # ... + + # Disable this library with Qt < 5.9.0 + meta.broken = builtins.compareVersions qtbase.version "5.9.0" < 0; +} +</programlisting> + </para> + + <formalpara> + <title>Adding a library to Nixpkgs</title> + <para> + Add a Qt library to <filename>all-packages.nix</filename> by adding it to the + collection inside <literal>mkLibsForQt5</literal>. This ensures that the + library is built with every available version of Qt as needed. + <example xml:id='qt-library-all-packages-nix'> + <title>Adding a Qt library to <filename>all-packages.nix</filename></title> +<programlisting> +{ + # ... + + mkLibsForQt5 = self: with self; { + # ... + + mylib = callPackage ../path/to/mylib {}; + }; + + # ... +} +</programlisting> + </example> + </para> + </formalpara> + + <formalpara> + <title>Adding an application to Nixpkgs</title> + <para> + Add a Qt application to <filename>all-packages.nix</filename> using + <literal>libsForQt5.callPackage</literal> instead of the usual + <literal>callPackage</literal>. The former ensures that all dependencies + are built with the same version of Qt. + <example xml:id='qt-application-all-packages-nix'> + <title>Adding a Qt application to <filename>all-packages.nix</filename></title> +<programlisting> +{ + # ... + + myapp = libsForQt5.callPackage ../path/to/myapp/ {}; + + # ... +} +</programlisting> + </example> + </para> + </formalpara> + </section> diff --git a/nixpkgs/doc/languages-frameworks/vim.section.md b/nixpkgs/doc/languages-frameworks/vim.section.md index c450a09f7bd2..537e7b93e523 100644 --- a/nixpkgs/doc/languages-frameworks/vim.section.md +++ b/nixpkgs/doc/languages-frameworks/vim.section.md @@ -21,7 +21,7 @@ At the moment we support three different methods for managing plugins: Adding custom .vimrc lines can be done using the following code: -``` +```nix vim_configurable.customize { # `name` specifies the name of the executable and package name = "vim-with-plugins"; @@ -32,11 +32,11 @@ vim_configurable.customize { } ``` -This configuration is used when vim is invoked with the command specified as name, in this case `vim-with-plugins`. +This configuration is used when Vim is invoked with the command specified as name, in this case `vim-with-plugins`. For Neovim the `configure` argument can be overridden to achieve the same: -``` +```nix neovim.override { configure = { customRC = '' @@ -46,10 +46,10 @@ neovim.override { } ``` -If you want to use `neovim-qt` as a graphical editor, you can configure it by overriding neovim in an overlay -or passing it an overridden neovimn: +If you want to use `neovim-qt` as a graphical editor, you can configure it by overriding Neovim in an overlay +or passing it an overridden Neovimn: -``` +```nix neovim-qt.override { neovim = neovim.override { configure = { @@ -63,16 +63,16 @@ neovim-qt.override { ## Managing plugins with Vim packages -To store you plugins in Vim packages (the native vim plugin manager, see `:help packages`) the following example can be used: +To store you plugins in Vim packages (the native Vim plugin manager, see `:help packages`) the following example can be used: -``` +```nix vim_configurable.customize { vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; { # loaded on launch start = [ youcompleteme fugitive ]; # manually loadable by calling `:packadd $plugin-name` - # however, if a vim plugin has a dependency that is not explicitly listed in - # opt that dependency will always be added to start to avoid confusion. + # however, if a Vim plugin has a dependency that is not explicitly listed in + # opt that dependency will always be added to start to avoid confusion. opt = [ phpCompletion elm-vim ]; # To automatically load a plugin when opening a filetype, add vimrc lines like: # autocmd FileType php :packadd phpCompletion @@ -83,7 +83,7 @@ vim_configurable.customize { `myVimPackage` is an arbitrary name for the generated package. You can choose any name you like. For Neovim the syntax is: -``` +```nix neovim.override { configure = { customRC = '' @@ -92,7 +92,7 @@ neovim.override { packages.myVimPackage = with pkgs.vimPlugins; { # see examples below how to use custom packages start = [ ]; - # If a vim plugin has a dependency that is not explicitly listed in + # If a Vim plugin has a dependency that is not explicitly listed in # opt that dependency will always be added to start to avoid confusion. opt = [ ]; }; @@ -102,7 +102,7 @@ neovim.override { The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.nix` to make it installable: -``` +```nix { packageOverrides = pkgs: with pkgs; { myVim = vim_configurable.customize { @@ -126,7 +126,7 @@ After that you can install your special grafted `myVim` or `myNeovim` packages. To use [vim-plug](https://github.com/junegunn/vim-plug) to manage your Vim plugins the following example can be used: -``` +```nix vim_configurable.customize { vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; { # loaded on launch @@ -137,7 +137,7 @@ vim_configurable.customize { For Neovim the syntax is: -``` +```nix neovim.override { configure = { customRC = '' @@ -161,89 +161,112 @@ assuming that "using latest version" is ok most of the time. First create a vim-scripts file having one plugin name per line. Example: - "tlib" - {'name': 'vim-addon-sql'} - {'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']} +``` +"tlib" +{'name': 'vim-addon-sql'} +{'filetype_regex': '\%(vim)$', 'names': ['reload', 'vim-dev-plugin']} +``` Such vim-scripts file can be read by VAM as well like this: - call vam#Scripts(expand('~/.vim-scripts'), {}) +```vim +call vam#Scripts(expand('~/.vim-scripts'), {}) +``` Create a default.nix file: - { nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }: - nixpkgs.vim_configurable.customize { name = "vim"; vimrcConfig.vam.pluginDictionaries = [ "vim-addon-vim2nix" ]; } +```nix +{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }: +nixpkgs.vim_configurable.customize { name = "vim"; vimrcConfig.vam.pluginDictionaries = [ "vim-addon-vim2nix" ]; } +``` Create a generate.vim file: - ActivateAddons vim-addon-vim2nix - let vim_scripts = "vim-scripts" - call nix#ExportPluginsForNix({ - \ 'path_to_nixpkgs': eval('{"'.substitute(substitute(substitute($NIX_PATH, ':', ',', 'g'), '=',':', 'g'), '\([:,]\)', '"\1"',"g").'"}')["nixpkgs"], - \ 'cache_file': '/tmp/vim2nix-cache', - \ 'try_catch': 0, - \ 'plugin_dictionaries': ["vim-addon-manager"]+map(readfile(vim_scripts), 'eval(v:val)') - \ }) +```vim +ActivateAddons vim-addon-vim2nix +let vim_scripts = "vim-scripts" +call nix#ExportPluginsForNix({ +\ 'path_to_nixpkgs': eval('{"'.substitute(substitute(substitute($NIX_PATH, ':', ',', 'g'), '=',':', 'g'), '\([:,]\)', '"\1"',"g").'"}')["nixpkgs"], +\ 'cache_file': '/tmp/vim2nix-cache', +\ 'try_catch': 0, +\ 'plugin_dictionaries': ["vim-addon-manager"]+map(readfile(vim_scripts), 'eval(v:val)') +\ }) +``` Then run - nix-shell -p vimUtils.vim_with_vim2nix --command "vim -c 'source generate.vim'" +```bash +nix-shell -p vimUtils.vim_with_vim2nix --command "vim -c 'source generate.vim'" +``` You should get a Vim buffer with the nix derivations (output1) and vam.pluginDictionaries (output2). -You can add your vim to your system's configuration file like this and start it by "vim-my": +You can add your Vim to your system's configuration file like this and start it by "vim-my": - my-vim = - let plugins = let inherit (vimUtils) buildVimPluginFrom2Nix; in { - copy paste output1 here - }; in vim_configurable.customize { - name = "vim-my"; - - vimrcConfig.vam.knownPlugins = plugins; # optional - vimrcConfig.vam.pluginDictionaries = [ - copy paste output2 here - ]; - - # Pathogen would be - # vimrcConfig.pathogen.knownPlugins = plugins; # plugins - # vimrcConfig.pathogen.pluginNames = ["tlib"]; - }; +``` +my-vim = + let plugins = let inherit (vimUtils) buildVimPluginFrom2Nix; in { + copy paste output1 here + }; in vim_configurable.customize { + name = "vim-my"; + + vimrcConfig.vam.knownPlugins = plugins; # optional + vimrcConfig.vam.pluginDictionaries = [ + copy paste output2 here + ]; + # Pathogen would be + # vimrcConfig.pathogen.knownPlugins = plugins; # plugins + # vimrcConfig.pathogen.pluginNames = ["tlib"]; + }; +``` Sample output1: - "reload" = buildVimPluginFrom2Nix { # created by nix#NixDerivation - name = "reload"; - src = fetchgit { - url = "git://github.com/xolox/vim-reload"; - rev = "0a601a668727f5b675cb1ddc19f6861f3f7ab9e1"; - sha256 = "0vb832l9yxj919f5hfg6qj6bn9ni57gnjd3bj7zpq7d4iv2s4wdh"; - }; - dependencies = ["nim-misc"]; +``` +"reload" = buildVimPluginFrom2Nix { # created by nix#NixDerivation + name = "reload"; + src = fetchgit { + url = "git://github.com/xolox/vim-reload"; + rev = "0a601a668727f5b675cb1ddc19f6861f3f7ab9e1"; + sha256 = "0vb832l9yxj919f5hfg6qj6bn9ni57gnjd3bj7zpq7d4iv2s4wdh"; + }; + dependencies = ["nim-misc"]; - }; - [...] +}; +[...] +``` Sample output2: - [ - ''vim-addon-manager'' - ''tlib'' - { "name" = ''vim-addon-sql''; } - { "filetype_regex" = ''\%(vim)$$''; "names" = [ ''reload'' ''vim-dev-plugin'' ]; } - ] - +```nix +[ + ''vim-addon-manager'' + ''tlib'' + { "name" = ''vim-addon-sql''; } + { "filetype_regex" = ''\%(vim)$$''; "names" = [ ''reload'' ''vim-dev-plugin'' ]; } +] +``` ## Adding new plugins to nixpkgs -In `pkgs/misc/vim-plugins/vim-plugin-names` we store the plugin names -for all vim plugins we automatically generate plugins for. -The format of this file `github username/github repository`: -For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`. -After adding your plugin to this file run the `./update.py` in the same folder. -This will updated a file called `generated.nix` and make your plugin accessible in the -`vimPlugins` attribute set (`vimPlugins.nerdtree` in our example). -If additional steps to the build process of the plugin are required, add an -override to the `pkgs/misc/vim-plugins/default.nix` in the same directory. +Nix expressions for Vim plugins are stored in [pkgs/misc/vim-plugins](/pkgs/misc/vim-plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](/pkgs/misc/vim-plugins/update.py). This creates a [generated.nix](/pkgs/misc/vim-plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](/pkgs/misc/vim-plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`. + +Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](/pkgs/misc/vim-plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added: + +``` +deoplete-fish = super.deoplete-fish.overrideAttrs(old: { + dependencies = with super; [ deoplete-nvim vim-fish ]; +}); +``` + +Sometimes plugins require an override that must be changed when the plugin is updated. This can cause issues when Vim plugins are auto-updated but the associated override isn't updated. For these plugins, the override should be written so that it specifies all information required to install the plugin, and running `./update.py` doesn't change the derivation for the plugin. Manually updating the override is required to update these types of plugins. An example of such a plugin is `LanguageClient-neovim`. + +To add a new plugin: + + 1. run `./update.py` and create a commit named "vimPlugins: Update", + 2. add the new plugin to [vim-plugin-names](/pkgs/misc/vim-plugins/vim-plugin-names) and add overrides if required to [overrides.nix](/pkgs/misc/vim-plugins/overrides.nix), + 3. run `./update.py` again and create a commit named "vimPlugins.[name]: init at [version]" (where `name` and `version` can be found in [generated.nix](/pkgs/misc/vim-plugins/generated.nix)), and + 4. create a pull request. ## Important repositories @@ -252,4 +275,3 @@ override to the `pkgs/misc/vim-plugins/default.nix` in the same directory. - [vim2nix](https://github.com/MarcWeber/vim-addon-vim2nix) which generates the .nix code - diff --git a/nixpkgs/doc/package-specific-user-notes.xml b/nixpkgs/doc/package-specific-user-notes.xml index ef9198d1de29..196c760251f0 100644 --- a/nixpkgs/doc/package-specific-user-notes.xml +++ b/nixpkgs/doc/package-specific-user-notes.xml @@ -409,11 +409,19 @@ overrides = self: super: rec { </section> <section xml:id="sec-citrix"> - <title>Citrix Receiver</title> + <title>Citrix Receiver & Citrix Workspace App</title> <para> - The <link xlink:href="https://www.citrix.com/products/receiver/">Citrix - Receiver</link> is a remote desktop viewer which provides access to + <note> + <para> + Please note that the <literal>citrix_receiver</literal> package has been deprecated since its + development was <link xlink:href="https://docs.citrix.com/en-us/citrix-workspace-app.html">discontinued by upstream</link> + and will be replaced by <link xlink:href="https://www.citrix.com/products/workspace-app/">the citrix workspace app</link>. + </para> + </note> + <link xlink:href="https://www.citrix.com/products/receiver/">Citrix Receiver</link> and + <link xlink:href="https://www.citrix.com/products/workspace-app/">Citrix Workspace App</link> + are a remote desktop viewers which provide access to <link xlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link> installations. </para> @@ -423,30 +431,35 @@ overrides = self: super: rec { <para> The tarball archive needs to be downloaded manually as the license - agreements of the vendor need to be accepted first. This is available at - the - <link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">download - page at citrix.com</link>. Then run <literal>nix-prefetch-url - file://$PWD/linuxx64-$version.tar.gz</literal>. With the archive available + agreements of the vendor for + <link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">Citrix Receiver</link> + or <link xlink:href="https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html">Citrix Workspace</link> + need to be accepted first. + Then run <command>nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz</command>. + With the archive available in the store the package can be built and installed with Nix. </para> - <para> - <emphasis>Note: it's recommended to install <literal>Citrix - Receiver</literal> using <literal>nix-env -i</literal> or globally to - ensure that the <literal>.desktop</literal> files are installed properly - into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't be possible to - open <literal>.ica</literal> files automatically from the browser to start - a Citrix connection.</emphasis> - </para> + <warning> + <title>Caution with <command>nix-shell</command> installs</title> + <para> + It's recommended to install <literal>Citrix Receiver</literal> + and/or <literal>Citrix Workspace</literal> using + <literal>nix-env -i</literal> or globally to + ensure that the <literal>.desktop</literal> files are installed properly + into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't be possible to + open <literal>.ica</literal> files automatically from the browser to start + a Citrix connection. + </para> + </warning> </section> <section xml:id="sec-citrix-custom-certs"> <title>Custom certificates</title> <para> - The <literal>Citrix Receiver</literal> in <literal>nixpkgs</literal> trusts - several certificates + The <literal>Citrix Receiver</literal> and <literal>Citrix Workspace App</literal> + in <literal>nixpkgs</literal> trust several certificates <link xlink:href="https://curl.haxx.se/docs/caextract.html">from the Mozilla database</link> by default. However several companies using Citrix might require their own corporate certificate. On distros with imperative @@ -459,7 +472,7 @@ overrides = self: super: rec { <programlisting> <![CDATA[with import <nixpkgs> { config.allowUnfree = true; }; let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in -citrix_receiver.override { +citrix_workspace.override { # the same applies for `citrix_receiver` if used. inherit extraCerts; }]]> </programlisting> diff --git a/nixpkgs/doc/stdenv.xml b/nixpkgs/doc/stdenv.xml index fbb84b03a8d5..fe5929656565 100644 --- a/nixpkgs/doc/stdenv.xml +++ b/nixpkgs/doc/stdenv.xml @@ -786,7 +786,7 @@ passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ] set, the default value is used, which is <literal>$prePhases unpackPhase patchPhase $preConfigurePhases configurePhase $preBuildPhases buildPhase checkPhase $preInstallPhases installPhase - fixupPhase $preDistPhases distPhase $postPhases</literal>. + fixupPhase installCheckPhase $preDistPhases distPhase $postPhases</literal>. </para> <para> Usually, if you just want to add a few phases, it’s more convenient @@ -1601,6 +1601,16 @@ installTargets = "install-bin install-doc";</programlisting> <title>Variables controlling the fixup phase</title> <varlistentry> <term> + <varname>dontFixup</varname> + </term> + <listitem> + <para> + Set to true to skip the fixup phase. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> <varname>dontStrip</varname> </term> <listitem> |