pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

CVS commit: pkgsrc/doc



Module Name:    pkgsrc
Committed By:   nia
Date:           Sun Feb 13 11:16:54 UTC 2022

Modified Files:
        pkgsrc/doc: pkgsrc.html pkgsrc.txt

Log Message:
doc/pkgsrc.*: regen


To generate a diff of this commit:
cvs rdiff -u -r1.333 -r1.334 pkgsrc/doc/pkgsrc.html
cvs rdiff -u -r1.331 -r1.332 pkgsrc/doc/pkgsrc.txt

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: pkgsrc/doc/pkgsrc.html
diff -u pkgsrc/doc/pkgsrc.html:1.333 pkgsrc/doc/pkgsrc.html:1.334
--- pkgsrc/doc/pkgsrc.html:1.333        Fri Feb 11 08:06:21 2022
+++ pkgsrc/doc/pkgsrc.html      Sun Feb 13 11:16:54 2022
@@ -221,10 +221,9 @@ builds)</a></span></dt>
 <dd><dl>
 <dt><span class="sect1"><a href="#creating.common">14.1. Common types of packages</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#creating.perl-module">14.1.1. Perl modules</a></span></dt>
-<dt><span class="sect2"><a href="#creating.python-module">14.1.2. Python modules and programs</a></span></dt>
-<dt><span class="sect2"><a href="#creating.R-package">14.1.3. R packages</a></span></dt>
-<dt><span class="sect2"><a href="#creating.TeX-package">14.1.4. TeXlive packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.python-module">14.1.1. Python modules and programs</a></span></dt>
+<dt><span class="sect2"><a href="#creating.R-package">14.1.2. R packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.TeX-package">14.1.3. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">14.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">14.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
@@ -3189,10 +3188,9 @@ anymore, you can remove that file and ru
 <dd><dl>
 <dt><span class="sect1"><a href="#creating.common">14.1. Common types of packages</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#creating.perl-module">14.1.1. Perl modules</a></span></dt>
-<dt><span class="sect2"><a href="#creating.python-module">14.1.2. Python modules and programs</a></span></dt>
-<dt><span class="sect2"><a href="#creating.R-package">14.1.3. R packages</a></span></dt>
-<dt><span class="sect2"><a href="#creating.TeX-package">14.1.4. TeXlive packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.python-module">14.1.1. Python modules and programs</a></span></dt>
+<dt><span class="sect2"><a href="#creating.R-package">14.1.2. R packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.TeX-package">14.1.3. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">14.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">14.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
@@ -5066,10 +5064,9 @@ ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site
 <dl class="toc">
 <dt><span class="sect1"><a href="#creating.common">14.1. Common types of packages</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="#creating.perl-module">14.1.1. Perl modules</a></span></dt>
-<dt><span class="sect2"><a href="#creating.python-module">14.1.2. Python modules and programs</a></span></dt>
-<dt><span class="sect2"><a href="#creating.R-package">14.1.3. R packages</a></span></dt>
-<dt><span class="sect2"><a href="#creating.TeX-package">14.1.4. TeXlive packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.python-module">14.1.1. Python modules and programs</a></span></dt>
+<dt><span class="sect2"><a href="#creating.R-package">14.1.2. R packages</a></span></dt>
+<dt><span class="sect2"><a href="#creating.TeX-package">14.1.3. TeXlive packages</a></span></dt>
 </dl></dd>
 <dt><span class="sect1"><a href="#creating.examples">14.2. Examples</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="#creating.nvu">14.2.1. How the www/nvu package came into pkgsrc</a></span></dt></dl></dd>
@@ -5093,20 +5090,16 @@ install the utilities <span class="comma
 <li class="step">
 <p>Choose one of the top-level directories as the category in
 which you want to place your package. You can also create a directory of
-your own (maybe called <code class="filename">local</code>). In that category
-directory, create another directory for your package and change into
-it:</p>
-<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>mkdir <em class="replaceable"><code>category</code></em>/<em 
class="replaceable"><code>package</code></em></code></strong>
-<code class="prompt">$</code> <strong class="userinput"><code>cd <em class="replaceable"><code>category</code></em>/<em class="replaceable"><code>package</code></em></code></strong></pre>
+your own (maybe called <code class="filename">local</code>). Change into that
+category directory:</p>
+<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>cd <em class="replaceable"><code>category</code></em></code></strong></pre>
 </li>
 <li class="step">
-<p>Run the program <span class="command"><strong>url2pkg</strong></span>, which will ask
-you for a URL. Enter the URL of the distribution file (in most cases a
-<code class="filename">.tar.gz</code> file) and watch how the basic ingredients
-of your package are created automatically. The distribution file is
-extracted automatically to fill in some details in the
-<code class="filename">Makefile</code> that would otherwise have to be done
-manually:</p>
+<p>Run the program <span class="command"><strong>url2pkg</strong></span>, passing as
+argument the URL of the distribution file (in most cases a
+<code class="filename">.tar.gz</code> file). This will download the distribution
+file and create the necessary files of the package, based on what's in
+the distribution file:</p>
 <pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>url2pkg <em 
class="replaceable"><code>https://www.example.org/packages/package-1.0.tar.gz</code></em></code></strong></pre>
 </li>
 <li class="step">
@@ -5120,7 +5113,7 @@ file just before the last line. If the
 <code class="filename">buildlink3.mk</code> file does not exist, it must be
 created first. The <code class="filename">buildlink3.mk</code> file makes sure
 that the package's include files and libraries are provided.</p>
-<p>If you just need binaries from a package, add a
+<p>If you just need binaries from a dependent package, add a
 <code class="varname">DEPENDS</code> line to the Makefile, which specifies the
 version of the dependency and where it can be found in pkgsrc. This line
 should be placed in the third paragraph. If the dependency is only
@@ -5130,13 +5123,13 @@ instead of <code class="varname">DEPENDS
 The difference between <code class="varname">TOOL_DEPENDS</code> and
 <code class="varname">BUILD_DEPENDS</code> occurs when cross-compiling:
 <code class="varname">TOOL_DEPENDS</code> are <span class="emphasis"><em>native</em></span>
-packages, i.e. packages for the architecture where the package
-is built;
+packages, i.e. packages for the platform where the package is built;
 <code class="varname">BUILD_DEPENDS</code> are <span class="emphasis"><em>target</em></span>
-packages, i.e. packages for the architecture for which the package
-is built. There is also <code class="varname">TEST_DEPENDS</code>, which is used
-to specify a dependency used only for testing the resulting package
-built, using the upstream project's included test suite.
+packages, i.e. packages for the platform for which the package
+is built. There is also <code class="varname">TEST_DEPENDS</code>, which
+specifies a dependency used only for testing the resulting package
+built, using the upstream project's included test suite, on the native
+platform.
 Your package may then look like this:</p>
 <pre class="programlisting">
 [...]
@@ -5162,18 +5155,19 @@ find instructions for the most common ca
 over there, you can hopefully continue here.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake clean</strong></span> to clean the working
 directory from the extracted files. Besides these files, a lot of cache
-files and other system information has been saved in the working
-directory, which may become wrong after you edited the
+files and other system information have been saved in the working
+directory, which may have become outdated after you edited the
 <code class="filename">Makefile</code>.</p></li>
 <li class="step">
 <p>Now, run <span class="command"><strong>bmake</strong></span> to build the package. For
 the various things that can go wrong in this phase, consult <a class="xref" href="#fixes" title="Chapter�21.�Making your package work">Chapter�21, <i>Making your package work</i></a>.</p>
-<p>If the extracted files from the package need to be fixed, run multiple rounds of these commands:</p>
-<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>make</code></strong>
+<p>If the extracted files from the package need to be fixed, run
+multiple rounds of these commands:</p>
+<pre class="screen"><code class="prompt">$</code> <strong class="userinput"><code>bmake</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>pkgvi ${WRKSRC}/some/file/that/does/not/compile</code></strong>
 <code class="prompt">$</code> <strong class="userinput"><code>mkpatches</code></strong>
-<code class="prompt">$</code> <strong class="userinput"><code>make mps</code></strong>
-<code class="prompt">$</code> <strong class="userinput"><code>make clean</code></strong></pre>
+<code class="prompt">$</code> <strong class="userinput"><code>bmake mps</code></strong>
+<code class="prompt">$</code> <strong class="userinput"><code>bmake clean</code></strong></pre>
 </li>
 <li class="step"><p>When the package builds fine, the next step is to install
 the package. Run <span class="command"><strong>bmake install</strong></span> and hope that
@@ -5192,12 +5186,11 @@ empty list of files. To fix this, run <s
 and <span class="command"><strong>bmake install</strong></span> again. Now the package is
 registered with the list of files from
 <code class="filename">PLIST</code>.</p></li>
-<li class="step"><p>Run <span class="command"><strong>bmake package</strong></span> to create a binary
-package from the set of installed files.</p></li>
 <li class="step"><p>Run <span class="command"><strong>bmake clean update</strong></span> to run everything
 from above again in a single step, making sure that the PLIST is correct
 and the whole package is created as intended.</p></li>
-<li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see if there's anything left to do.</p></li>
+<li class="step"><p>Run <span class="command"><strong>pkglint</strong></span> to see if there's anything
+left to do.</p></li>
 <li class="step"><p>Commit the package to pkgsrc-wip or main pkgsrc; see <a class="xref" href="#submit" title="Chapter�23.�Submitting and Committing">Chapter�23, <i>Submitting and 
Committing</i></a>.</p></li>
 </ol></div>
 <div class="sect1">
@@ -5205,13 +5198,7 @@ and the whole package is created as inte
 <a name="creating.common"></a>14.1.�Common types of packages</h2></div></div></div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="creating.perl-module"></a>14.1.1.�Perl modules</h3></div></div></div>
-<p>Simple Perl modules are handled automatically by
-<span class="command"><strong>url2pkg</strong></span>, including dependencies.</p>
-</div>
-<div class="sect2">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="creating.python-module"></a>14.1.2.�Python modules and programs</h3></div></div></div>
+<a name="creating.python-module"></a>14.1.1.�Python modules and programs</h3></div></div></div>
 <p>Python modules and programs packages are easily created using a
 set of predefined variables.</p>
 <p>
@@ -5266,7 +5253,7 @@ of supported packages.</p>
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="creating.R-package"></a>14.1.3.�R packages</h3></div></div></div>
+<a name="creating.R-package"></a>14.1.2.�R packages</h3></div></div></div>
 <p>Simple R packages from <a class="ulink" href="https://cran.r-project.org/web/packages/available_packages_by_name.html"; target="_top">CRAN</a>
 are handled automatically by <span class="command"><strong>R2pkg</strong></span>, which is
 available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/R2pkg/index.html"; target="_top"><code class="filename">pkgtools/R2pkg</code></a>.
@@ -5281,7 +5268,7 @@ package should be reviewed for correctne
 </div>
 <div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="creating.TeX-package"></a>14.1.4.�TeXlive packages</h3></div></div></div>
+<a name="creating.TeX-package"></a>14.1.3.�TeXlive packages</h3></div></div></div>
 <p>TeXlive packages from <a class="ulink" href="https://www.ctan.org/"; target="_top">CTAN</a> are handled automatically by
 <span class="command"><strong>texlive2pkg</strong></span>, which is available in <a href="https://cdn.NetBSD.org/pub/pkgsrc/current/pkgsrc/pkgtools/texlive2pkg/index.html"; target="_top"><code 
class="filename">pkgtools/texlive2pkg</code></a>.</p>
 <p>If the TeXlive package name is not known, it may be useful to
@@ -11035,33 +11022,9 @@ Currently, this means NetBSD on x86, ARM
 <code class="varname">PKGSRC_MKPIE</code> was enabled by default after the pkgsrc-2021Q3 branch.
 </p>
 </div>
-</div>
-<div class="sect2">
-<div class="titlepage"><div><div><h3 class="title">
-<a name="hardening.mechanisms.disabled"></a>B.1.2.�Not enabled by default</h3></div></div></div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.disabled.repro"></a>B.1.2.1.�PKGSRC_MKREPRO</h4></div></div></div>
-<p>
-With this option, pkgsrc will try to build packages reproducibly. This allows
-packages built from the same tree and with the same options, to produce
-identical results bit by bit. This option should be combined with ASLR and
-<code class="varname">PKGSRC_MKPIE</code> to avoid predictable address offsets for
-attackers attempting to exploit security vulnerabilities.
-</p>
-<p>
-More details can be found here:
-</p>
-<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-<a class="ulink" href="https://reproducible-builds.org/"; target="_top">Reproducible Builds - a set of software development practices that create an independently-verifiable path from source to 
binary code</a>
-</p></li></ul></div>
-<p>
-More work likely needs to be done before pkgsrc is fully reproducible.
-</p>
-</div>
-<div class="sect3">
-<div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.enabled.relro"></a>B.1.2.2.�PKGSRC_USE_RELRO</h4></div></div></div>
+<a name="hardening.mechanisms.enabled.relro"></a>B.1.1.4.�PKGSRC_USE_RELRO</h4></div></div></div>
 <p>
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
@@ -11069,7 +11032,7 @@ difficult in some cases.
 <p>Two different mitigation levels are available:</p>
 <div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
 <li class="listitem"><p>
-partial: the ELF sections are reordered so that internal data sections
+partial (the default): the ELF sections are reordered so that internal data sections
 precede the program's own data sections, and non-PLT GOT is read-only;
 </p></li>
 <li class="listitem"><p>
@@ -11090,9 +11053,33 @@ More details can be found here:
 <a class="ulink" href="https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro"; target="_top">Hardening ELF binaries using Relocation Read-Only (RELRO)</a>
 </p></li></ul></div>
 </div>
+</div>
+<div class="sect2">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="hardening.mechanisms.disabled"></a>B.1.2.�Not enabled by default</h3></div></div></div>
+<div class="sect3">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="hardening.mechanisms.disabled.repro"></a>B.1.2.1.�PKGSRC_MKREPRO</h4></div></div></div>
+<p>
+With this option, pkgsrc will try to build packages reproducibly. This allows
+packages built from the same tree and with the same options, to produce
+identical results bit by bit. This option should be combined with ASLR and
+<code class="varname">PKGSRC_MKPIE</code> to avoid predictable address offsets for
+attackers attempting to exploit security vulnerabilities.
+</p>
+<p>
+More details can be found here:
+</p>
+<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+<a class="ulink" href="https://reproducible-builds.org/"; target="_top">Reproducible Builds - a set of software development practices that create an independently-verifiable path from source to 
binary code</a>
+</p></li></ul></div>
+<p>
+More work likely needs to be done before pkgsrc is fully reproducible.
+</p>
+</div>
 <div class="sect3">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="hardening.mechanisms.disabled.stackcheck"></a>B.1.2.3.�PKGSRC_USE_STACK_CHECK</h4></div></div></div>
+<a name="hardening.mechanisms.disabled.stackcheck"></a>B.1.2.2.�PKGSRC_USE_STACK_CHECK</h4></div></div></div>
 <p>
 This uses <code class="literal">-fstack-check</code> with GCC for
 another stack protection mitigation.

Index: pkgsrc/doc/pkgsrc.txt
diff -u pkgsrc/doc/pkgsrc.txt:1.331 pkgsrc/doc/pkgsrc.txt:1.332
--- pkgsrc/doc/pkgsrc.txt:1.331 Fri Feb 11 08:06:21 2022
+++ pkgsrc/doc/pkgsrc.txt       Sun Feb 13 11:16:54 2022
@@ -205,10 +205,9 @@ II. The pkgsrc developer's guide
 
         14.1. Common types of packages
 
-            14.1.1. Perl modules
-            14.1.2. Python modules and programs
-            14.1.3. R packages
-            14.1.4. TeXlive packages
+            14.1.1. Python modules and programs
+            14.1.2. R packages
+            14.1.3. TeXlive packages
 
         14.2. Examples
 
@@ -2731,10 +2730,9 @@ Table of Contents
 
     14.1. Common types of packages
 
-        14.1.1. Perl modules
-        14.1.2. Python modules and programs
-        14.1.3. R packages
-        14.1.4. TeXlive packages
+        14.1.1. Python modules and programs
+        14.1.2. R packages
+        14.1.3. TeXlive packages
 
     14.2. Examples
 
@@ -4215,10 +4213,9 @@ Table of Contents
 
 14.1. Common types of packages
 
-    14.1.1. Perl modules
-    14.1.2. Python modules and programs
-    14.1.3. R packages
-    14.1.4. TeXlive packages
+    14.1.1. Python modules and programs
+    14.1.2. R packages
+    14.1.3. TeXlive packages
 
 14.2. Examples
 
@@ -4238,17 +4235,14 @@ package involves only a few steps.
 
  3. Choose one of the top-level directories as the category in which you want
     to place your package. You can also create a directory of your own (maybe
-    called local). In that category directory, create another directory for
-    your package and change into it:
+    called local). Change into that category directory:
 
-    $ mkdir category/package
-    $ cd category/package
+    $ cd category
 
- 4. Run the program url2pkg, which will ask you for a URL. Enter the URL of the
-    distribution file (in most cases a .tar.gz file) and watch how the basic
-    ingredients of your package are created automatically. The distribution
-    file is extracted automatically to fill in some details in the Makefile
-    that would otherwise have to be done manually:
+ 4. Run the program url2pkg, passing as argument the URL of the distribution
+    file (in most cases a .tar.gz file). This will download the distribution
+    file and create the necessary files of the package, based on what's in the
+    distribution file:
 
     $ url2pkg https://www.example.org/packages/package-1.0.tar.gz
 
@@ -4261,18 +4255,18 @@ package involves only a few steps.
     buildlink3.mk file makes sure that the package's include files and
     libraries are provided.
 
-    If you just need binaries from a package, add a DEPENDS line to the
-    Makefile, which specifies the version of the dependency and where it can be
-    found in pkgsrc. This line should be placed in the third paragraph. If the
-    dependency is only needed for building the package, but not when using it,
-    use TOOL_DEPENDS or BUILD_DEPENDS instead of DEPENDS. The difference
-    between TOOL_DEPENDS and BUILD_DEPENDS occurs when cross-compiling:
-    TOOL_DEPENDS are native packages, i.e. packages for the architecture where
-    the package is built; BUILD_DEPENDS are target packages, i.e. packages for
-    the architecture for which the package is built. There is also
-    TEST_DEPENDS, which is used to specify a dependency used only for testing
-    the resulting package built, using the upstream project's included test
-    suite. Your package may then look like this:
+    If you just need binaries from a dependent package, add a DEPENDS line to
+    the Makefile, which specifies the version of the dependency and where it
+    can be found in pkgsrc. This line should be placed in the third paragraph.
+    If the dependency is only needed for building the package, but not when
+    using it, use TOOL_DEPENDS or BUILD_DEPENDS instead of DEPENDS. The
+    difference between TOOL_DEPENDS and BUILD_DEPENDS occurs when
+    cross-compiling: TOOL_DEPENDS are native packages, i.e. packages for the
+    platform where the package is built; BUILD_DEPENDS are target packages,
+    i.e. packages for the platform for which the package is built. There is
+    also TEST_DEPENDS, which specifies a dependency used only for testing the
+    resulting package built, using the upstream project's included test suite,
+    on the native platform. Your package may then look like this:
 
     [...]
 
@@ -4296,9 +4290,9 @@ package involves only a few steps.
     there, you can hopefully continue here.
 
  8. Run bmake clean to clean the working directory from the extracted files.
-    Besides these files, a lot of cache files and other system information has
-    been saved in the working directory, which may become wrong after you
-    edited the Makefile.
+    Besides these files, a lot of cache files and other system information have
+    been saved in the working directory, which may have become outdated after
+    you edited the Makefile.
 
  9. Now, run bmake to build the package. For the various things that can go
     wrong in this phase, consult Chapter 21, Making your package work.
@@ -4306,11 +4300,11 @@ package involves only a few steps.
     If the extracted files from the package need to be fixed, run multiple
     rounds of these commands:
 
-    $ make
+    $ bmake
     $ pkgvi ${WRKSRC}/some/file/that/does/not/compile
     $ mkpatches
-    $ make mps
-    $ make clean
+    $ bmake mps
+    $ bmake clean
 
 10. When the package builds fine, the next step is to install the package. Run 
     bmake install and hope that everything works.
@@ -4327,26 +4321,18 @@ package involves only a few steps.
     deinstall and bmake install again. Now the package is registered with the
     list of files from PLIST.
 
-14. Run bmake package to create a binary package from the set of installed
-    files.
-
-15. Run bmake clean update to run everything from above again in a single step,
+14. Run bmake clean update to run everything from above again in a single step,
     making sure that the PLIST is correct and the whole package is created as
     intended.
 
-16. Run pkglint to see if there's anything left to do.
+15. Run pkglint to see if there's anything left to do.
 
-17. Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting
+16. Commit the package to pkgsrc-wip or main pkgsrc; see Chapter 23, Submitting
     and Committing.
 
 14.1. Common types of packages
 
-14.1.1. Perl modules
-
-Simple Perl modules are handled automatically by url2pkg, including
-dependencies.
-
-14.1.2. Python modules and programs
+14.1.1. Python modules and programs
 
 Python modules and programs packages are easily created using a set of
 predefined variables.
@@ -4386,7 +4372,7 @@ PYTHON_VERSIONED_DEPENDENCIES=dialog
 
 Look inside versioned_dependencies.mk for a list of supported packages.
 
-14.1.3. R packages
+14.1.2. R packages
 
 Simple R packages from CRAN are handled automatically by R2pkg, which is
 available in pkgtools/R2pkg. Individual packages (and optionally their
@@ -4396,7 +4382,7 @@ file as part of each R package on CRAN. 
 information and creates or updates a package in the canonical form. The
 resulting package should be reviewed for correctness.
 
-14.1.4. TeXlive packages
+14.1.3. TeXlive packages
 
 TeXlive packages from CTAN are handled automatically by texlive2pkg, which is
 available in pkgtools/texlive2pkg.
@@ -9034,32 +9020,16 @@ PIE. Currently, this means NetBSD on x86
 
 PKGSRC_MKPIE was enabled by default after the pkgsrc-2021Q3 branch.
 
-B.1.2. Not enabled by default
-
-B.1.2.1. PKGSRC_MKREPRO
-
-With this option, pkgsrc will try to build packages reproducibly. This allows
-packages built from the same tree and with the same options, to produce
-identical results bit by bit. This option should be combined with ASLR and
-PKGSRC_MKPIE to avoid predictable address offsets for attackers attempting to
-exploit security vulnerabilities.
-
-More details can be found here:
-
-  * Reproducible Builds - a set of software development practices that create
-    an independently-verifiable path from source to binary code
-
-More work likely needs to be done before pkgsrc is fully reproducible.
-
-B.1.2.2. PKGSRC_USE_RELRO
+B.1.1.4. PKGSRC_USE_RELRO
 
 This also makes the exploitation of some security vulnerabilities more
 difficult in some cases.
 
 Two different mitigation levels are available:
 
-  * partial: the ELF sections are reordered so that internal data sections
-    precede the program's own data sections, and non-PLT GOT is read-only;
+  * partial (the default): the ELF sections are reordered so that internal data
+    sections precede the program's own data sections, and non-PLT GOT is
+    read-only;
 
   * full: in addition to partial RELRO, every relocation is performed
     immediately when starting the program, allowing the entire GOT to be
@@ -9073,7 +9043,24 @@ More details can be found here:
 
   * Hardening ELF binaries using Relocation Read-Only (RELRO)
 
-B.1.2.3. PKGSRC_USE_STACK_CHECK
+B.1.2. Not enabled by default
+
+B.1.2.1. PKGSRC_MKREPRO
+
+With this option, pkgsrc will try to build packages reproducibly. This allows
+packages built from the same tree and with the same options, to produce
+identical results bit by bit. This option should be combined with ASLR and
+PKGSRC_MKPIE to avoid predictable address offsets for attackers attempting to
+exploit security vulnerabilities.
+
+More details can be found here:
+
+  * Reproducible Builds - a set of software development practices that create
+    an independently-verifiable path from source to binary code
+
+More work likely needs to be done before pkgsrc is fully reproducible.
+
+B.1.2.2. PKGSRC_USE_STACK_CHECK
 
 This uses -fstack-check with GCC for another stack protection mitigation.
 



Home | Main Index | Thread Index | Old Index