2009-02-10 23:29:42 +00:00
|
|
|
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
|
|
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
|
|
|
xml:id="chap-meta">
|
2018-05-01 23:54:21 +00:00
|
|
|
|
<title>Meta-attributes</title>
|
|
|
|
|
<para>
|
|
|
|
|
Nix packages can declare <emphasis>meta-attributes</emphasis> that contain
|
|
|
|
|
information about a package such as a description, its homepage, its license,
|
|
|
|
|
and so on. For instance, the GNU Hello package has a <varname>meta</varname>
|
|
|
|
|
declaration like this:
|
2009-02-10 23:29:42 +00:00
|
|
|
|
<programlisting>
|
2018-05-22 17:25:09 +00:00
|
|
|
|
meta = with stdenv.lib; {
|
2009-02-10 23:29:42 +00:00
|
|
|
|
description = "A program that produces a familiar, friendly greeting";
|
|
|
|
|
longDescription = ''
|
|
|
|
|
GNU Hello is a program that prints "Hello, world!" when you run it.
|
|
|
|
|
It is fully customizable.
|
|
|
|
|
'';
|
2018-12-01 18:22:13 +00:00
|
|
|
|
homepage = https://www.gnu.org/software/hello/manual/;
|
2018-05-22 17:25:09 +00:00
|
|
|
|
license = licenses.gpl3Plus;
|
|
|
|
|
maintainers = [ maintainers.eelco ];
|
|
|
|
|
platforms = platforms.all;
|
2009-02-10 23:29:42 +00:00
|
|
|
|
};
|
|
|
|
|
</programlisting>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
Meta-attributes are not passed to the builder of the package. Thus, a change
|
|
|
|
|
to a meta-attribute doesn’t trigger a recompilation of the package. The
|
|
|
|
|
value of a meta-attribute must be a string.
|
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
The meta-attributes of a package can be queried from the command-line using
|
|
|
|
|
<command>nix-env</command>:
|
2009-02-10 23:29:42 +00:00
|
|
|
|
<screen>
|
2019-06-17 11:25:50 +00:00
|
|
|
|
<prompt>$ </prompt>nix-env -qa hello --json
|
2014-07-27 12:22:48 +00:00
|
|
|
|
{
|
|
|
|
|
"hello": {
|
|
|
|
|
"meta": {
|
|
|
|
|
"description": "A program that produces a familiar, friendly greeting",
|
2018-12-01 18:22:13 +00:00
|
|
|
|
"homepage": "https://www.gnu.org/software/hello/manual/",
|
2014-07-27 12:22:48 +00:00
|
|
|
|
"license": {
|
|
|
|
|
"fullName": "GNU General Public License version 3 or later",
|
|
|
|
|
"shortName": "GPLv3+",
|
|
|
|
|
"url": "http://www.fsf.org/licensing/licenses/gpl.html"
|
|
|
|
|
},
|
|
|
|
|
"longDescription": "GNU Hello is a program that prints \"Hello, world!\" when you run it.\nIt is fully customizable.\n",
|
|
|
|
|
"maintainers": [
|
2014-07-27 13:21:27 +00:00
|
|
|
|
"Ludovic Court\u00e8s <ludo@gnu.org>"
|
2014-07-27 12:22:48 +00:00
|
|
|
|
],
|
|
|
|
|
"platforms": [
|
|
|
|
|
"i686-linux",
|
|
|
|
|
"x86_64-linux",
|
|
|
|
|
"armv5tel-linux",
|
|
|
|
|
"armv7l-linux",
|
2017-12-05 10:27:45 +00:00
|
|
|
|
"mips32-linux",
|
2014-07-27 12:22:48 +00:00
|
|
|
|
"x86_64-darwin",
|
|
|
|
|
"i686-cygwin",
|
|
|
|
|
"i686-freebsd",
|
|
|
|
|
"x86_64-freebsd",
|
|
|
|
|
"i686-openbsd",
|
|
|
|
|
"x86_64-openbsd"
|
|
|
|
|
],
|
2015-09-22 18:23:23 +00:00
|
|
|
|
"position": "/home/user/dev/nixpkgs/pkgs/applications/misc/hello/default.nix:14"
|
2014-07-27 12:22:48 +00:00
|
|
|
|
},
|
|
|
|
|
"name": "hello-2.9",
|
|
|
|
|
"system": "x86_64-linux"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-27 11:52:11 +00:00
|
|
|
|
|
2009-02-10 23:29:42 +00:00
|
|
|
|
</screen>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
<command>nix-env</command> knows about the <varname>description</varname>
|
|
|
|
|
field specifically:
|
2009-02-10 23:29:42 +00:00
|
|
|
|
<screen>
|
2019-06-17 11:25:50 +00:00
|
|
|
|
<prompt>$ </prompt>nix-env -qa hello --description
|
2009-02-10 23:29:42 +00:00
|
|
|
|
hello-2.3 A program that produces a familiar, friendly greeting
|
|
|
|
|
</screen>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</para>
|
|
|
|
|
<section xml:id="sec-standard-meta-attributes">
|
|
|
|
|
<title>Standard meta-attributes</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
It is expected that each meta-attribute is one of the following:
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>description</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
A short (one-line) description of the package. This is shown by
|
|
|
|
|
<command>nix-env -q --description</command> and also on the Nixpkgs
|
|
|
|
|
release pages.
|
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
Don’t include a period at the end. Don’t include newline characters.
|
|
|
|
|
Capitalise the first character. For brevity, don’t repeat the name of
|
|
|
|
|
package — just describe what it does.
|
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
Wrong: <literal>"libpng is a library that allows you to decode PNG
|
|
|
|
|
images."</literal>
|
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
Right: <literal>"A library for decoding PNG images"</literal>
|
|
|
|
|
</para>
|
2009-03-03 13:47:46 +00:00
|
|
|
|
</listitem>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>longDescription</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
2015-04-30 11:46:31 +00:00
|
|
|
|
<listitem>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
<para>
|
|
|
|
|
An arbitrarily long description of the package.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>branch</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Release branch. Used to specify that a package is not going to receive
|
|
|
|
|
updates that are not in this branch; for example, Linux kernel 3.0 is
|
|
|
|
|
supposed to be updated to 3.0.X, not 3.1.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>homepage</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The package’s homepage. Example:
|
2018-12-01 18:22:13 +00:00
|
|
|
|
<literal>https://www.gnu.org/software/hello/manual/</literal>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>downloadPage</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The page where a link to the current version can be found. Example:
|
2018-12-01 18:22:13 +00:00
|
|
|
|
<literal>https://ftp.gnu.org/gnu/hello/</literal>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2019-05-10 16:55:29 +00:00
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
|
|
|
|
<varname>changelog</varname>
|
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
A link or a list of links to the location of Changelog for a package.
|
|
|
|
|
A link may use expansion to refer to the correct changelog version.
|
|
|
|
|
Example:
|
|
|
|
|
<literal>"https://git.savannah.gnu.org/cgit/hello.git/plain/NEWS?h=v${version}"</literal>
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>license</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The license, or licenses, for the package. One from the attribute set
|
|
|
|
|
defined in
|
|
|
|
|
<link
|
2015-04-30 11:46:31 +00:00
|
|
|
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix">
|
2018-05-01 23:54:21 +00:00
|
|
|
|
<filename>nixpkgs/lib/licenses.nix</filename></link>. At this moment
|
|
|
|
|
using both a list of licenses and a single license is valid. If the
|
|
|
|
|
license field is in the form of a list representation, then it means that
|
|
|
|
|
parts of the package are licensed differently. Each license should
|
|
|
|
|
preferably be referenced by their attribute. The non-list attribute value
|
|
|
|
|
can also be a space delimited string representation of the contained
|
|
|
|
|
attribute shortNames or spdxIds. The following are all valid examples:
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Single license referenced by attribute (preferred)
|
|
|
|
|
<literal>stdenv.lib.licenses.gpl3</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Single license referenced by its attribute shortName (frowned upon)
|
|
|
|
|
<literal>"gpl3"</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Single license referenced by its attribute spdxId (frowned upon)
|
|
|
|
|
<literal>"GPL-3.0"</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Multiple licenses referenced by attribute (preferred) <literal>with
|
|
|
|
|
stdenv.lib.licenses; [ asl20 free ofl ]</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Multiple licenses referenced as a space delimited string of attribute
|
|
|
|
|
shortNames (frowned upon) <literal>"asl20 free ofl"</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
For details, see <xref linkend='sec-meta-license'/>.
|
|
|
|
|
</para>
|
2015-04-30 11:46:31 +00:00
|
|
|
|
</listitem>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>maintainers</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
A list of names and e-mail addresses of the maintainers of this Nix
|
|
|
|
|
expression. If you would like to be a maintainer of a package, you may
|
|
|
|
|
want to add yourself to
|
|
|
|
|
<link
|
2018-03-18 05:16:43 +00:00
|
|
|
|
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix"><filename>nixpkgs/maintainers/maintainer-list.nix</filename></link>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
and write something like <literal>[ stdenv.lib.maintainers.alice
|
|
|
|
|
stdenv.lib.maintainers.bob ]</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>priority</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The <emphasis>priority</emphasis> of the package, used by
|
|
|
|
|
<command>nix-env</command> to resolve file name conflicts between
|
|
|
|
|
packages. See the Nix manual page for <command>nix-env</command> for
|
|
|
|
|
details. Example: <literal>"10"</literal> (a low-priority package).
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>platforms</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The list of Nix platform types on which the package is supported. Hydra
|
|
|
|
|
builds packages according to the platform specified. If no platform is
|
|
|
|
|
specified, the package does not have prebuilt binaries. An example is:
|
2013-11-04 22:31:08 +00:00
|
|
|
|
<programlisting>
|
2014-07-27 11:52:11 +00:00
|
|
|
|
meta.platforms = stdenv.lib.platforms.linux;
|
2013-11-04 22:31:08 +00:00
|
|
|
|
</programlisting>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
Attribute Set <varname>stdenv.lib.platforms</varname> defines
|
|
|
|
|
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix">
|
|
|
|
|
various common lists</link> of platforms types.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
dovecot, opensmtpd: add link to test in `meta.tests`
Rationale
---------
Currently, tests are hard to discover. For instance, someone updating
`dovecot` might not notice that the interaction of `dovecot` with
`opensmtpd` is handled in the `opensmtpd.nix` test.
And even for someone updating `opensmtpd`, it requires manual work to go
check in `nixos/tests` whether there is actually a test, especially
given not so many packages in `nixpkgs` have tests and this is thus most
of the time useless.
Finally, for the reviewer, it is much easier to check that the “Tested
via one or more NixOS test(s)” has been checked if the file modified
already includes the list of relevant tests.
Implementation
--------------
Currently, this commit only adds the metadata in the package. Each
element of the `meta.tests` attribute is a derivation that, when it
builds successfully, means the test has passed (ie. following the same
convention as NixOS tests).
Future Work
-----------
In the future, the tools could be made aware of this `meta.tests`
attribute, and for instance a `--with-tests` could be added to
`nix-build` so that it also builds all the tests. Or a `--without-tests`
to build without all the tests. @Profpatsch described in his NixCon talk
such systems.
Another thing that would help in the future would be the possibility to
reasonably easily have cross-derivation nix tests without the whole
NixOS VM stack. @7c6f434c already proposed such a system.
This RFC currently handles none of these concerns. Only the addition of
`meta.tests` as metadata to be used by maintainers to remember to run
relevant tests.
2018-08-04 03:18:28 +00:00
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
|
|
|
|
<varname>tests</varname>
|
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
2018-11-11 13:55:23 +00:00
|
|
|
|
<warning>
|
|
|
|
|
<para>
|
|
|
|
|
This attribute is special in that it is not actually under the
|
|
|
|
|
<literal>meta</literal> attribute set but rather under the
|
2019-06-17 17:03:43 +00:00
|
|
|
|
<literal>passthru</literal> attribute set. This is due to how
|
|
|
|
|
<literal>meta</literal> attributes work, and the fact that they
|
|
|
|
|
are supposed to contain only metadata, not derivations.
|
2018-11-11 13:55:23 +00:00
|
|
|
|
</para>
|
|
|
|
|
</warning>
|
dovecot, opensmtpd: add link to test in `meta.tests`
Rationale
---------
Currently, tests are hard to discover. For instance, someone updating
`dovecot` might not notice that the interaction of `dovecot` with
`opensmtpd` is handled in the `opensmtpd.nix` test.
And even for someone updating `opensmtpd`, it requires manual work to go
check in `nixos/tests` whether there is actually a test, especially
given not so many packages in `nixpkgs` have tests and this is thus most
of the time useless.
Finally, for the reviewer, it is much easier to check that the “Tested
via one or more NixOS test(s)” has been checked if the file modified
already includes the list of relevant tests.
Implementation
--------------
Currently, this commit only adds the metadata in the package. Each
element of the `meta.tests` attribute is a derivation that, when it
builds successfully, means the test has passed (ie. following the same
convention as NixOS tests).
Future Work
-----------
In the future, the tools could be made aware of this `meta.tests`
attribute, and for instance a `--with-tests` could be added to
`nix-build` so that it also builds all the tests. Or a `--without-tests`
to build without all the tests. @Profpatsch described in his NixCon talk
such systems.
Another thing that would help in the future would be the possibility to
reasonably easily have cross-derivation nix tests without the whole
NixOS VM stack. @7c6f434c already proposed such a system.
This RFC currently handles none of these concerns. Only the addition of
`meta.tests` as metadata to be used by maintainers to remember to run
relevant tests.
2018-08-04 03:18:28 +00:00
|
|
|
|
<para>
|
|
|
|
|
An attribute set with as values tests. A test is a derivation, which
|
|
|
|
|
builds successfully when the test passes, and fails to build otherwise. A
|
2018-11-11 13:47:49 +00:00
|
|
|
|
derivation that is a test needs to have <literal>meta.timeout</literal>
|
|
|
|
|
defined.
|
dovecot, opensmtpd: add link to test in `meta.tests`
Rationale
---------
Currently, tests are hard to discover. For instance, someone updating
`dovecot` might not notice that the interaction of `dovecot` with
`opensmtpd` is handled in the `opensmtpd.nix` test.
And even for someone updating `opensmtpd`, it requires manual work to go
check in `nixos/tests` whether there is actually a test, especially
given not so many packages in `nixpkgs` have tests and this is thus most
of the time useless.
Finally, for the reviewer, it is much easier to check that the “Tested
via one or more NixOS test(s)” has been checked if the file modified
already includes the list of relevant tests.
Implementation
--------------
Currently, this commit only adds the metadata in the package. Each
element of the `meta.tests` attribute is a derivation that, when it
builds successfully, means the test has passed (ie. following the same
convention as NixOS tests).
Future Work
-----------
In the future, the tools could be made aware of this `meta.tests`
attribute, and for instance a `--with-tests` could be added to
`nix-build` so that it also builds all the tests. Or a `--without-tests`
to build without all the tests. @Profpatsch described in his NixCon talk
such systems.
Another thing that would help in the future would be the possibility to
reasonably easily have cross-derivation nix tests without the whole
NixOS VM stack. @7c6f434c already proposed such a system.
This RFC currently handles none of these concerns. Only the addition of
`meta.tests` as metadata to be used by maintainers to remember to run
relevant tests.
2018-08-04 03:18:28 +00:00
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
The NixOS tests are available as <literal>nixosTests</literal> in
|
|
|
|
|
parameters of derivations. For instance, the OpenSMTPD derivation
|
|
|
|
|
includes lines similar to:
|
|
|
|
|
<programlisting>
|
|
|
|
|
{ /* ... */, nixosTests }:
|
|
|
|
|
{
|
|
|
|
|
# ...
|
2018-11-11 13:55:23 +00:00
|
|
|
|
passthru.tests = {
|
dovecot, opensmtpd: add link to test in `meta.tests`
Rationale
---------
Currently, tests are hard to discover. For instance, someone updating
`dovecot` might not notice that the interaction of `dovecot` with
`opensmtpd` is handled in the `opensmtpd.nix` test.
And even for someone updating `opensmtpd`, it requires manual work to go
check in `nixos/tests` whether there is actually a test, especially
given not so many packages in `nixpkgs` have tests and this is thus most
of the time useless.
Finally, for the reviewer, it is much easier to check that the “Tested
via one or more NixOS test(s)” has been checked if the file modified
already includes the list of relevant tests.
Implementation
--------------
Currently, this commit only adds the metadata in the package. Each
element of the `meta.tests` attribute is a derivation that, when it
builds successfully, means the test has passed (ie. following the same
convention as NixOS tests).
Future Work
-----------
In the future, the tools could be made aware of this `meta.tests`
attribute, and for instance a `--with-tests` could be added to
`nix-build` so that it also builds all the tests. Or a `--without-tests`
to build without all the tests. @Profpatsch described in his NixCon talk
such systems.
Another thing that would help in the future would be the possibility to
reasonably easily have cross-derivation nix tests without the whole
NixOS VM stack. @7c6f434c already proposed such a system.
This RFC currently handles none of these concerns. Only the addition of
`meta.tests` as metadata to be used by maintainers to remember to run
relevant tests.
2018-08-04 03:18:28 +00:00
|
|
|
|
basic-functionality-and-dovecot-integration = nixosTests.opensmtpd;
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
</programlisting>
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term>
|
|
|
|
|
<varname>timeout</varname>
|
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
A timeout (in seconds) for building the derivation. If the derivation
|
|
|
|
|
takes longer than this time to build, it can fail due to breaking the
|
|
|
|
|
timeout. However, all computers do not have the same computing power,
|
|
|
|
|
hence some builders may decide to apply a multiplicative factor to this
|
|
|
|
|
value. When filling this value in, try to keep it approximately
|
|
|
|
|
consistent with other values already present in
|
|
|
|
|
<literal>nixpkgs</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>hydraPlatforms</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The list of Nix platform types for which the Hydra instance at
|
|
|
|
|
<literal>hydra.nixos.org</literal> will build the package. (Hydra is the
|
|
|
|
|
Nix-based continuous build system.) It defaults to the value of
|
|
|
|
|
<varname>meta.platforms</varname>. Thus, the only reason to set
|
|
|
|
|
<varname>meta.hydraPlatforms</varname> is if you want
|
|
|
|
|
<literal>hydra.nixos.org</literal> to build the package on a subset of
|
|
|
|
|
<varname>meta.platforms</varname>, or not at all, e.g.
|
2013-11-04 22:31:08 +00:00
|
|
|
|
<programlisting>
|
|
|
|
|
meta.platforms = stdenv.lib.platforms.linux;
|
|
|
|
|
meta.hydraPlatforms = [];
|
|
|
|
|
</programlisting>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>broken</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
If set to <literal>true</literal>, the package is marked as “broken”,
|
|
|
|
|
meaning that it won’t show up in <literal>nix-env -qa</literal>, and
|
|
|
|
|
cannot be built or installed. Such packages should be removed from
|
|
|
|
|
Nixpkgs eventually unless they are fixed.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>updateWalker</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
If set to <literal>true</literal>, the package is tested to be updated
|
|
|
|
|
correctly by the <literal>update-walker.sh</literal> script without
|
|
|
|
|
additional settings. Such packages have <varname>meta.version</varname>
|
|
|
|
|
set and their homepage (or the page specified by
|
|
|
|
|
<varname>meta.downloadPage</varname>) contains a direct link to the
|
|
|
|
|
package tarball.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
</variablelist>
|
|
|
|
|
</section>
|
|
|
|
|
<section xml:id="sec-meta-license">
|
|
|
|
|
<title>Licenses</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The <varname>meta.license</varname> attribute should preferrably contain a
|
|
|
|
|
value from <varname>stdenv.lib.licenses</varname> defined in
|
|
|
|
|
<link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix">
|
|
|
|
|
<filename>nixpkgs/lib/licenses.nix</filename></link>, or in-place license
|
|
|
|
|
description of the same format if the license is unlikely to be useful in
|
|
|
|
|
another expression.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Although it's typically better to indicate the specific license, a few
|
|
|
|
|
generic options are available:
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>stdenv.lib.licenses.free</varname>, <varname>"free"</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Catch-all for free software licenses not listed above.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>stdenv.lib.licenses.unfreeRedistributable</varname>, <varname>"unfree-redistributable"</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Unfree package that can be redistributed in binary form. That is, it’s
|
|
|
|
|
legal to redistribute the <emphasis>output</emphasis> of the derivation.
|
|
|
|
|
This means that the package can be included in the Nixpkgs channel.
|
|
|
|
|
</para>
|
|
|
|
|
<para>
|
|
|
|
|
Sometimes proprietary software can only be redistributed unmodified.
|
|
|
|
|
Make sure the builder doesn’t actually modify the original binaries;
|
|
|
|
|
otherwise we’re breaking the license. For instance, the NVIDIA X11
|
|
|
|
|
drivers can be redistributed unmodified, but our builder applies
|
|
|
|
|
<command>patchelf</command> to make them work. Thus, its license is
|
|
|
|
|
<varname>"unfree"</varname> and it cannot be included in the Nixpkgs
|
|
|
|
|
channel.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>stdenv.lib.licenses.unfree</varname>, <varname>"unfree"</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Unfree package that cannot be redistributed. You can build it yourself,
|
|
|
|
|
but you cannot redistribute the output of the derivation. Thus it cannot
|
|
|
|
|
be included in the Nixpkgs channel.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
<varlistentry>
|
2018-06-01 01:03:37 +00:00
|
|
|
|
<term>
|
|
|
|
|
<varname>stdenv.lib.licenses.unfreeRedistributableFirmware</varname>, <varname>"unfree-redistributable-firmware"</varname>
|
2018-05-01 23:54:21 +00:00
|
|
|
|
</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
This package supplies unfree, redistributable firmware. This is a
|
|
|
|
|
separate value from <varname>unfree-redistributable</varname> because
|
|
|
|
|
not everybody cares whether firmware is free.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
</variablelist>
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
2009-02-10 23:29:42 +00:00
|
|
|
|
</chapter>
|