nixpkgs docs: give linked things IDs

doc/cross-compilation.xml

···
    </para>
 
    <qandaset>
-    <qandaentry>
+    <qandaentry xml:id="cross-qa-build-c-program-in-build-environment">
      <question>
       <para>
        What if my package's build system needs to build a C program to be run
···
       </para>
      </answer>
     </qandaentry>
-    <qandaentry>
+    <qandaentry xml:id="cross-qa-fails-to-find-ar">
      <question>
       <para>
        My package fails to find <command>ar</command>.
···
       </para>
      </answer>
     </qandaentry>
-    <qandaentry>
+    <qandaentry xml:id="cross-testsuite-runs-host-code">
      <question>
       <para>
        My package's testsuite needs to run host platform code.

doc/multiple-output.xml

···
          xmlns:xlink="http://www.w3.org/1999/xlink"
          xml:id="chap-multiple-output">
  <title>Multiple-output packages</title>
- <section>
+ <section xml:id="sec-multiple-outputs-introduction">
   <title>Introduction</title>
 
   <para>
···
    </para>
   </note>
  </section>
- <section>
+ <section xml:id="sec-multiple-outputs-installing">
   <title>Installing a split package</title>
 
   <para>
···
    </listitem>
   </itemizedlist>
  </section>
- <section>
+ <section xml:id="sec-multiple-outputs-using-split-packages">
   <title>Using a split package</title>
 
   <para>
···
    also added. (See <xref linkend="multiple-output-file-type-groups" />.)
   </para>
  </section>
- <section>
+ <section xml:id="sec-multiple-outputs-">
   <title>Writing a split derivation</title>
 
   <para>
···
    </variablelist>
   </section>
 
-  <section>
+  <section xml:id="sec-multiple-outputs-caveats">
    <title>Common caveats</title>
 
    <itemizedlist>

doc/package-notes.xml

···
  </section>
 <!--============================================================-->
 <!--
-<section>
+<section xml:id="sec-package-notes-gnome">
   <title>Gnome</title>
   <para>* Expression is auto-generated</para>
   <para>* How to update</para>
···
 -->
 <!--============================================================-->
 <!--
-<section>
+<section xml:id="sec-package-notes-gcc">
   <title>GCC</title>
   <para>…</para>
 </section>

doc/release-notes.xml

···
 <article xmlns="http://docbook.org/ns/docbook"
          xmlns:xlink="http://www.w3.org/1999/xlink">
  <title>Nixpkgs Release Notes</title>
- <section>
+ <section xml:id="release-notes-0.14">
   <title>Release 0.14 (June 4, 2012)</title>
 
   <para>
···
    packages by numerous contributors. For details, see the commit logs.
   </para>
  </section>
- <section>
+ <section xml:id="release-notes-0.13">
   <title>Release 0.13 (February 5, 2010)</title>
 
   <para>
···
    </itemizedlist>
   </para>
  </section>
- <section>
+ <section xml:id="release-notes-0.12">
   <title>Release 0.12 (April 24, 2009)</title>
 
   <para>
···
    <literal>nix-dev</literal> mailing list.
   </para>
  </section>
- <section>
+ <section xml:id="release-notes-0.11">
   <title>Release 0.11 (September 11, 2007)</title>
 
   <para>
···
    Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
   </para>
  </section>
- <section>
+ <section xml:id="release-notes-0.10">
   <title>Release 0.10 (October 12, 2006)</title>
 
   <note>
···
    Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
   </para>
  </section>
- <section>
+ <section xml:id="release-notes-0.9">
   <title>Release 0.9 (January 31, 2006)</title>
 
   <para>
···
    Martin Bravenboer, Rob Vermaas and Roy van den Broek.
   </para>
  </section>
- <section>
+ <section xml:id="release-notes-0.8">
   <title>Release 0.8 (April 11, 2005)</title>
 
   <para>
···
    </itemizedlist>
   </para>
  </section>
- <section>
+ <section xml:id="release-notes-0.7">
   <title>Release 0.7 (March 14, 2005)</title>
 
   <itemizedlist>

doc/reviewing-contributions.xml

···
    </listitem>
   </itemizedlist>
 
-  <example>
+  <example xml:id="reviewing-contributions-sample-package-update">
    <title>Sample template for a package update review</title>
 <screen>
 ##### Reviewed points
···
    </listitem>
   </itemizedlist>
 
-  <example>
+  <example xml:id="reviewing-contributions-sample-new-package">
    <title>Sample template for a new package review</title>
 <screen>
 ##### Reviewed points
···
    </listitem>
   </itemizedlist>
 
-  <example>
+  <example xml:id="reviewing-contributions-sample-module-update">
    <title>Sample template for a module update review</title>
 <screen>
 ##### Reviewed points
···
    </listitem>
   </itemizedlist>
 
-  <example>
+  <example xml:id="reviewing-contributions-sample-new-module">
    <title>Sample template for a new module review</title>
 <screen>
 ##### Reviewed points

doc/stdenv.xml

···
    platforms relative to the new derivation's, and whether they are propagated.
    The platform distinctions are motivated by cross compilation; see
    <xref linkend="chap-cross"/> for exactly what each platform means.
-   <footnote>
+   <footnote xml:id="footnote-stdenv-ignored-build-platform">
     <para>
      The build platform is ignored because it is a mere implementation detail
      of the package satisfying the dependency: As a general programming
···
    out only for dependencies whose host platform matches the new derivation's
    build platform–i.e. which run on the platform where the new derivation
    will be built.
-   <footnote>
+   <footnote xml:id="footnote-stdenv-native-dependencies-in-path">
     <para>
      Currently, that means for native builds all dependencies are put on the
      <envar>PATH</envar>. But in the future that may not be the case for sake
···
    <link xlink:href="https://en.wikipedia.org/wiki/Natural_deduction">Natural
    Deduction</link> using the inference rules. This probably seems a bit
    obtuse, but so is the bash code that actually implements it!
-   <footnote>
+   <footnote xml:id="footnote-stdenv-find-inputs-location">
     <para>
      The <function>findInputs</function> function, currently residing in
      <filename>pkgs/stdenv/generic/setup.sh</filename>, implements the
···
        By default, the configure phase applies some special hackery to all
        files called <filename>ltmain.sh</filename> before running the configure
        script in order to improve the purity of Libtool-based packages
-       <footnote>
+       <footnote xml:id="footnote-stdenv-sys-lib-search-path">
         <para>
          It clears the
          <varname>sys_lib_<replaceable>*</replaceable>search_path</varname>
···
        or a subset to control exactly which platform flags are passed.
        Compilers and other tools should use this to also pass the target
        platform, for example.
-       <footnote>
+       <footnote xml:id="footnote-stdenv-build-time-guessing-impurity">
         <para>
          Eventually these will be passed when in native builds too, to improve
          determinism: build-time guessing, as is done today, is a risk of
···
        Controls whether the installCheck phase is executed. By default it is
        skipped, but if <varname>doInstallCheck</varname> is set to true, the
        installCheck phase is usually executed. Thus you should set
-       <programlisting>doInstallCheck = true;</programlisting>
+<programlisting>doInstallCheck = true;</programlisting>
        in the derivation to enable install checks. The exception is cross
        compilation. Cross compiled builds never run tests, no matter how
        <varname>doInstallCheck</varname> is set, as the newly-built program
···
        <command>clang</command> is to be used. Secondly, this helps packages
        not get confused when cross-compiling, in which case multiple Bintools
        Wrappers may simultaneously be in use.
-       <footnote>
+       <footnote xml:id="footnote-stdenv-per-platform-wrapper">
         <para>
          Each wrapper targets a single platform, so if binaries for multiple
          platforms are needed, the underlying binaries must be wrapped multiple