In Nixpkgs, there are generally three different names associated with a package:
The name attribute of the
derivation (excluding the version part). This is what most users
see, in particular when using
nix-env.
The variable name used for the instantiated package
in all-packages.nix, and when passing it as a
dependency to other functions. This is what Nix expression authors
see. It can also be used when installing using nix-env
-iA.
The filename for (the directory containing) the Nix expression.
Most of the time, these are the same. For instance, the package
e2fsprogs has a name attribute
"e2fsprogs-, is
bound to the variable name version"e2fsprogs in
all-packages.nix, and the Nix expression is in
pkgs/os-specific/linux/e2fsprogs/default.nix.
There are a few naming guidelines:
Generally, try to stick to the upstream package name.
Don’t use uppercase letters in the
name attribute — e.g.,
"mplayer-1.0rc2" instead of
"MPlayer-1.0rc2".
The version part of the name
attribute must start with a digit (following a
dash) — e.g., "hello-0.3.1rc2".
If a package is not a release but a commit from a repository, then
the version part of the name must be the date of that
(fetched) commit. The date must be in "YYYY-MM-DD" format.
Also append "unstable" to the name - e.g.,
"pkgname-unstable-2014-09-23".
Dashes in the package name should be preserved
in new variable names, rather than converted to underscores
(which was convention up to around 2013 and most names
still have underscores instead of dashes) — e.g.,
http-parser instead of
http_parser.
If there are multiple versions of a package, this
should be reflected in the variable names in
all-packages.nix,
e.g. json-c-0-9 and json-c-0-11.
If there is an obvious “default” version, make an attribute like
json-c = json-c-0-9;.
See also Section 10.3.2, “Versioning”