glossary: refine the definition of "package"

This change follows the definition from aptitude, but using precise notions from Nix:

> package managers deal with packages: collections of files that are
> bundled together and can be installed and removed as a group.
> [...]
> If a package A depends upon another package B, then B is required
> for A to operate properly.
> [...]
> The job of a package manager is to present an interface which assists
> the user in managing the collection of packages installed on his or her system.
>
> -- <https://www.debian.org/doc/manuals/aptitude/pr01s02.en.html>

An interesting addition:

> Packages are abstractions defining the granularity at which users can act
> (add, remove, upgrade, etc.) on available software.
> A distribution is a collection of packages maintained (hopefully) coherently.
>
> -- Package Upgrades in FOSS Distributions: Details and Challenges
>    (Roberto Di Cosmo, Stefano Zacchiroli; 2009) <https://arxiv.org/pdf/0902.1610>

Notably these quotes and this change don't say anything about installation,
or what it means for software to be available. In practice, this is
handled downstream, e.g. in NixOS or Home Manager. Nix historically
provides rudimentary facilities for package management such as
`nix-env`, but I claim they are widely agreed upon being discouraged,
with plenty of arguments provided in <https://stop-using-nix-env.privatevoid.net>.

Similarly, the specific structure of packages is determined downstream,
since Nix is policy-free:

> Nix is policy-free; it provides mechanisms to implement various deployment policies, but does not enforce a specific one.
>
> -- The Purely Functional Software Deployment Model (Eelco Dolstra; 2006) <https://edolstra.github.io/pubs/phd-thesis.pdf>

Specifically, Nix mechanisms do not define what a package is supposed to be:

> It's worth noting that the Nix language is intended as a DSL for package and configuration management, but it has no notions of "packages" or "configurations".
>
> -- <https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0dbc00d>

This is why we say, Nix *allows* denoting packages in a certain way, but
doesn't enforce any particular way.

doc/manual/redirects.js

@@ -374,6 +374,7 @@ const redirects = {
   },
   "glossary.html": {
     "gloss-local-store": "store/types/local-store.html",
+    "package-attribute-set": "#package",
     "gloss-chroot-store": "store/types/local-store.html",
     "gloss-content-addressed-derivation": "#gloss-content-addressing-derivation",
   },

doc/manual/source/glossary.md

@@ -215,7 +215,7 @@
 
   > **Example**
   >
-  > Building and deploying software using Nix entails writing Nix expressions as a high-level description of packages and compositions thereof.
+  > Building and deploying software using Nix entails writing Nix expressions to describe [packages][package] and compositions thereof.
 
 - [reference]{#gloss-reference}
 
@@ -330,18 +330,17 @@
 
 - [package]{#package}
 
-  1. A software package; a collection of files and other data.
+  A software package; files that belong together for a particular purpose, and metadata.
 
-  2. A [package attribute set].
+  Nix represents files as [file system objects][file system object], and how they belong together is encoded as [references][reference] between [store objects][store object] that contain these file system objects.
 
-- [package attribute set]{#package-attribute-set}
+  The [Nix language] allows denoting packages in terms of [attribute sets](@docroot@/language/types.md#attribute-set) containing:
+  - attributes that refer to the files of a package, typically in the form of [derivation outputs](#output),
+  - attributes with metadata, such as information about how the package is supposed to be used.
 
-  An [attribute set](@docroot@/language/types.md#attribute-set) containing the attribute `type = "derivation";` (derivation for historical reasons), as well as other attributes, such as
-  - attributes that refer to the files of a [package], typically in the form of [derivation outputs](#output),
-  - attributes that declare something about how the package is supposed to be installed or used,
-  - other metadata or arbitrary attributes.
+  The exact shape of these attribute sets is up to convention.
 
-  [package attribute set]: #package-attribute-set
+  [package]: #package
 
 - [string interpolation]{#gloss-string-interpolation}