chore(3p/nix): unvendor tvix 0.1 r/4098

Nothing is using this now, and we'll likely never pick this up again,
but we learned a lot in the process.

Every now and then this breaks in some bizarre way on channel bumps
and it's just a waste of time to maintain that.

Change-Id: Idcf2f5acd4ca7070ce18d7149cbfc0d967dc0a44
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5632
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: lukegb <lukegb@tvl.fyi>
Autosubmit: tazjin <tazjin@tvl.su>

1 files changed, 0 insertions, 199 deletions

diff --git a/third_party/nix/doc/manual/glossary/glossary.xml b/third_party/nix/doc/manual/glossary/glossary.xml
deleted file mode 100644
index e3162ed8d469..000000000000
--- a/third_party/nix/doc/manual/glossary/glossary.xml
+++ /dev/null
@@ -1,199 +0,0 @@
-<appendix xmlns="http://docbook.org/ns/docbook"
-          xmlns:xlink="http://www.w3.org/1999/xlink"
-          xml:id="part-glossary">
-
-<title>Glossary</title>
-
-
-<glosslist>
-
-
-<glossentry xml:id="gloss-derivation"><glossterm>derivation</glossterm>
-
-  <glossdef><para>A description of a build action.  The result of a
-  derivation is a store object.  Derivations are typically specified
-  in Nix expressions using the <link
-  linkend="ssec-derivation"><function>derivation</function>
-  primitive</link>.  These are translated into low-level
-  <emphasis>store derivations</emphasis> (implicitly by
-  <command>nix-env</command> and <command>nix-build</command>, or
-  explicitly by <command>nix-instantiate</command>).</para></glossdef>
-
-</glossentry>
-
-
-<glossentry><glossterm>store</glossterm>
-
-  <glossdef><para>The location in the file system where store objects
-  live.  Typically <filename>/nix/store</filename>.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry><glossterm>store path</glossterm>
-
-  <glossdef><para>The location in the file system of a store object,
-  i.e., an immediate child of the Nix store
-  directory.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry><glossterm>store object</glossterm>
-
-  <glossdef><para>A file that is an immediate child of the Nix store
-  directory.  These can be regular files, but also entire directory
-  trees.  Store objects can be sources (objects copied from outside of
-  the store), derivation outputs (objects produced by running a build
-  action), or derivations (files describing a build
-  action).</para></glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-substitute"><glossterm>substitute</glossterm>
-
-  <glossdef><para>A substitute is a command invocation stored in the
-  Nix database that describes how to build a store object, bypassing
-  the normal build mechanism (i.e., derivations).  Typically, the
-  substitute builds the store object by downloading a pre-built
-  version of the store object from some server.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry><glossterm>purity</glossterm>
-
-  <glossdef><para>The assumption that equal Nix derivations when run
-  always produce the same output.  This cannot be guaranteed in
-  general (e.g., a builder can rely on external inputs such as the
-  network or the system time) but the Nix model assumes
-  it.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry><glossterm>Nix expression</glossterm>
-
-  <glossdef><para>A high-level description of software packages and
-  compositions thereof.  Deploying software using Nix entails writing
-  Nix expressions for your packages.  Nix expressions are translated
-  to derivations that are stored in the Nix store.  These derivations
-  can then be built.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-reference"><glossterm>reference</glossterm>
-
-  <glossdef>
-    <para>A store path <varname>P</varname> is said to have a
-    reference to a store path <varname>Q</varname> if the store object
-    at <varname>P</varname> contains the path <varname>Q</varname>
-    somewhere. The <emphasis>references</emphasis> of a store path are
-    the set of store paths to which it has a reference.
-    </para>
-    <para>A derivation can reference other derivations and sources
-    (but not output paths), whereas an output path only references other
-    output paths.
-    </para>
-  </glossdef>
-
-</glossentry>
-
-<glossentry xml:id="gloss-reachable"><glossterm>reachable</glossterm>
-
-  <glossdef><para>A store path <varname>Q</varname> is reachable from
-  another store path <varname>P</varname> if <varname>Q</varname> is in the
-  <link linkend="gloss-closure">closure</link> of the
-  <link linkend="gloss-reference">references</link> relation.
-  </para></glossdef>
-</glossentry>
-
-<glossentry xml:id="gloss-closure"><glossterm>closure</glossterm>
-
-  <glossdef><para>The closure of a store path is the set of store
-  paths that are directly or indirectly “reachable” from that store
-  path; that is, it’s the closure of the path under the <link
-  linkend="gloss-reference">references</link> relation. For a package, the
-  closure of its derivation is equivalent to the build-time
-  dependencies, while the closure of its output path is equivalent to its
-  runtime dependencies. For correct deployment it is necessary to deploy whole
-  closures, since otherwise at runtime files could be missing. The command
-  <command>nix-store -qR</command> prints out closures of store paths.
-  </para>
-  <para>As an example, if the store object at path <varname>P</varname> contains
-  a reference to path <varname>Q</varname>, then <varname>Q</varname> is
-  in the closure of <varname>P</varname>. Further, if <varname>Q</varname>
-  references <varname>R</varname> then <varname>R</varname> is also in
-  the closure of <varname>P</varname>.
-  </para></glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-output-path"><glossterm>output path</glossterm>
-
-  <glossdef><para>A store path produced by a derivation.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-deriver"><glossterm>deriver</glossterm>
-
-  <glossdef><para>The deriver of an <link
-  linkend="gloss-output-path">output path</link> is the store
-  derivation that built it.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-validity"><glossterm>validity</glossterm>
-
-  <glossdef><para>A store path is considered
-  <emphasis>valid</emphasis> if it exists in the file system, is
-  listed in the Nix database as being valid, and if all paths in its
-  closure are also valid.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-user-env"><glossterm>user environment</glossterm>
-
-  <glossdef><para>An automatically generated store object that
-  consists of a set of symlinks to “active” applications, i.e., other
-  store paths.  These are generated automatically by <link
-  linkend="sec-nix-env"><command>nix-env</command></link>.  See <xref
-  linkend="sec-profiles" />.</para>
-
-  </glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-profile"><glossterm>profile</glossterm>
-
-  <glossdef><para>A symlink to the current <link
-  linkend="gloss-user-env">user environment</link> of a user, e.g.,
-  <filename>/nix/var/nix/profiles/default</filename>.</para></glossdef>
-
-</glossentry>
-
-
-<glossentry xml:id="gloss-nar"><glossterm>NAR</glossterm>
-
-  <glossdef><para>A <emphasis>N</emphasis>ix
-  <emphasis>AR</emphasis>chive.  This is a serialisation of a path in
-  the Nix store.  It can contain regular files, directories and
-  symbolic links.  NARs are generated and unpacked using
-  <command>nix-store --dump</command> and <command>nix-store
-  --restore</command>.</para></glossdef>
-
-</glossentry>
-
-
-
-</glosslist>
-
-
-</appendix>