Change the metadata format to YAML

Change the metadata format to a single YAML file, with a slightly
different internal representation, whose default location is
docs/docknot.yaml.  The new docknot update command (or the
App::DocKnot::Update module) will convert from the old JSON format.
The new metadata format is checked against a schema when read.
DocKnot now depends on YAML::XS and Kwalify.

Word wrap numeric lists and, in Markdown output, quoted paragraphs.
Previously these preserved the original spacing from the input text
snippets.

Require paragraphs be indented by at least six spaces, not five, to be
treated as verbatim paragraphs and left unwrapped.  (Markdown
paragraphs can still use four spaces because they are wrapped in
markup lines.)

75 files changed, 4174 insertions, 0 deletions

diff --git a/t/data/update/ansicolor/docknot.yaml b/t/data/update/ansicolor/docknot.yaml
new file mode 100644
index 0000000..3cfc953
--- /dev/null
+++ b/t/data/update/ansicolor/docknot.yaml
@@ -0,0 +1,105 @@
+---
+blurb: |
+  Term::ANSIColor provides constants and simple functions for setting ANSI
+  text attributes, most notably colors.  It can be used to set the current
+  text attributes or to apply a set of attributes to a string and reset the
+  current text attributes at the end of that string.  Eight-color,
+  sixteen-color, and 256-color escape sequences are all supported.
+build:
+  lancaster: true
+  type: ExtUtils::MakeMaker
+copyrights:
+- holder: Russ Allbery <rra@cpan.org>
+  years: 1996-1998, 2000-2002, 2005-2006, 2008-2016
+- holder: Zenin
+  years: '1996'
+- holder: Kurt Starsinic <kstarsinic@gmail.com>
+  years: '2012'
+description: |
+  This Perl module is a simple and convenient interface to the ANSI terminal
+  escape sequences for color (from ECMA-48, also included in ISO 6429).  The
+  color sequences are provided in two forms, either as constants for each
+  color or via a function that takes the names of colors and returns the
+  appropriate escape codes or wraps them around the provided text.  The
+  non-color text style codes from ANSI X3.64 (bold, dark, underline, and
+  reverse, for example), which were also included in ECMA-48 and ISO 6429,
+  are also supported.  Also supported are the extended colors used for
+  sixteen-color and 256-color emulators.
+
+  This module is very stable, and I've used it in a wide variety of
+  applications.  It has been included in the core Perl distribution starting
+  with version 5.6.0, so you don't need to download and install it yourself
+  unless you have an old version of Perl or need a newer version of the
+  module than comes with your version of Perl.  I continue to maintain it as
+  a separate module, and the version included in Perl is resynced with mine
+  before each release.
+
+  The original module came out of a discussion in comp.lang.perl.misc and is
+  a combination of two approaches, one with constants by Zenin and one with
+  functions that I wrote.  I offered to maintain a combined module that
+  included both approaches.
+distribution:
+  section: devel
+  tarname: Term-ANSIColor
+  version: term-ansicolor
+docs:
+  user:
+  - name: docs
+    title: Module documentation
+  - name: thanks
+    title: Thanks and credits
+format: v1
+license:
+  name: Perl
+  notices: |
+    PUSH/POP support submitted 2007 by openmethods.com voice solutions
+maintainer: Russ Allbery <rra@cpan.org>
+name: Term::ANSIColor
+quote:
+  author: Dave van Domelen
+  text: |
+    Ah, September, when the sysadmins turn colors and fall off the trees....
+requirements: |
+  Term::ANSIColor is written in pure Perl and has no module dependencies
+  that aren't found in Perl core.  It should work with any version of Perl
+  after 5.6, although it hasn't been tested with old versions in some time.
+
+  In order to actually see color, you will need to use a terminal window
+  that supports the ANSI escape sequences for color.  Any recent version of
+  xterm, most xterm derivatives and replacements, and most telnet and ssh
+  clients for Windows and Macintosh should work, as will the MacOS X
+  Terminal application (although Terminal.app reportedly doesn't support 256
+  colors).  The console windows for Windows NT and Windows 2000 will not
+  work, as they do not even attempt to support ANSI X3.64.
+
+  For a complete (to my current knowledge) compatibility list, see the
+  Term::ANSIColor module documentation.  If you have any additions to the
+  table in the documentation, please send them to me.
+
+  The test suite requires Test::More (part of Perl since 5.6.2).  The
+  following additional Perl modules will be used by the test suite if
+  present:
+
+  * Devel::Cover
+  * Test::MinimumVersion
+  * Test::Perl::Critic
+  * Test::Pod
+  * Test::Pod::Coverage
+  * Test::Spelling
+  * Test::Strict
+  * Test::Synopsis
+  * Test::Warn
+
+  All are available on CPAN.  Those tests will be skipped if the modules are
+  not available.
+support:
+  cpan: Term-ANSIColor
+  email: rra@cpan.org
+  web: https://www.eyrie.org/~eagle/software/ansicolor/
+synopsis: simple ANSI text attribute control module
+vcs:
+  browse: https://git.eyrie.org/?p=perl/ansicolor.git
+  github: rra/ansicolor
+  type: Git
+  url: https://git.eyrie.org/git/perl/ansicolor.git
+version: '4.06'
diff --git a/t/data/update/ansicolor/old/blurb b/t/data/update/ansicolor/old/blurb
new file mode 100644
index 0000000..36c74f5
--- /dev/null
+++ b/t/data/update/ansicolor/old/blurb
@@ -0,0 +1,5 @@
+Term::ANSIColor provides constants and simple functions for setting ANSI
+text attributes, most notably colors.  It can be used to set the current
+text attributes or to apply a set of attributes to a string and reset the
+current text attributes at the end of that string.  Eight-color,
+sixteen-color, and 256-color escape sequences are all supported.
diff --git a/t/data/update/ansicolor/old/description b/t/data/update/ansicolor/old/description
new file mode 100644
index 0000000..b1e259a
--- /dev/null
+++ b/t/data/update/ansicolor/old/description
@@ -0,0 +1,22 @@
+This Perl module is a simple and convenient interface to the ANSI terminal
+escape sequences for color (from ECMA-48, also included in ISO 6429).  The
+color sequences are provided in two forms, either as constants for each
+color or via a function that takes the names of colors and returns the
+appropriate escape codes or wraps them around the provided text.  The
+non-color text style codes from ANSI X3.64 (bold, dark, underline, and
+reverse, for example), which were also included in ECMA-48 and ISO 6429,
+are also supported.  Also supported are the extended colors used for
+sixteen-color and 256-color emulators.
+
+This module is very stable, and I've used it in a wide variety of
+applications.  It has been included in the core Perl distribution starting
+with version 5.6.0, so you don't need to download and install it yourself
+unless you have an old version of Perl or need a newer version of the
+module than comes with your version of Perl.  I continue to maintain it as
+a separate module, and the version included in Perl is resynced with mine
+before each release.
+
+The original module came out of a discussion in comp.lang.perl.misc and is
+a combination of two approaches, one with constants by Zenin and one with
+functions that I wrote.  I offered to maintain a combined module that
+included both approaches.
diff --git a/t/data/update/ansicolor/old/metadata.json b/t/data/update/ansicolor/old/metadata.json
new file mode 100644
index 0000000..1dceffd
--- /dev/null
+++ b/t/data/update/ansicolor/old/metadata.json
@@ -0,0 +1,56 @@
+{
+    "name": "Term::ANSIColor",
+    "version": "4.06",
+    "synopsis": "simple ANSI text attribute control module",
+    "maintainer": "Russ Allbery <rra@cpan.org>",
+    "copyrights": [
+        {
+            "holder": "Russ Allbery <rra@cpan.org>",
+            "years": "1996-1998, 2000-2002, 2005-2006, 2008-2016",
+        },
+        {
+            "holder": "Zenin",
+            "years": "1996",
+        },
+        {
+            "holder": "Kurt Starsinic <kstarsinic@gmail.com>",
+            "years": "2012",
+        },
+    ],
+    "license": "Perl",
+    "build": {
+        "lancaster": true,
+        "type": "ExtUtils::MakeMaker",
+    },
+    "support": {
+        "cpan": "Term-ANSIColor",
+        "email": "rra@cpan.org",
+        "web": "https://www.eyrie.org/~eagle/software/ansicolor/",
+    },
+    "vcs": {
+        "type": "Git",
+        "url": "https://git.eyrie.org/git/perl/ansicolor.git",
+        "browse": "https://git.eyrie.org/?p=perl/ansicolor.git",
+        "github": "rra/ansicolor",
+    },
+    "quote": {
+        "author": "Dave van Domelen",
+    },
+    "distribution": {
+        "section": "devel",
+        "tarname": "Term-ANSIColor",
+        "version": "term-ansicolor",
+    },
+    "docs": {
+        "user": [
+            {
+                "name": "docs",
+                "title": "Module documentation",
+            },
+            {
+                "name": "thanks",
+                "title": "Thanks and credits",
+            },
+        ],
+    },
+}
diff --git a/t/data/update/ansicolor/old/notices b/t/data/update/ansicolor/old/notices
new file mode 100644
index 0000000..c38fa5a
--- /dev/null
+++ b/t/data/update/ansicolor/old/notices
@@ -0,0 +1 @@
+PUSH/POP support submitted 2007 by openmethods.com voice solutions
diff --git a/t/data/update/ansicolor/old/quote b/t/data/update/ansicolor/old/quote
new file mode 100644
index 0000000..21d524c
--- /dev/null
+++ b/t/data/update/ansicolor/old/quote
@@ -0,0 +1 @@
+Ah, September, when the sysadmins turn colors and fall off the trees....
diff --git a/t/data/update/ansicolor/old/requirements b/t/data/update/ansicolor/old/requirements
new file mode 100644
index 0000000..da259e0
--- /dev/null
+++ b/t/data/update/ansicolor/old/requirements
@@ -0,0 +1,32 @@
+Term::ANSIColor is written in pure Perl and has no module dependencies
+that aren't found in Perl core.  It should work with any version of Perl
+after 5.6, although it hasn't been tested with old versions in some time.
+
+In order to actually see color, you will need to use a terminal window
+that supports the ANSI escape sequences for color.  Any recent version of
+xterm, most xterm derivatives and replacements, and most telnet and ssh
+clients for Windows and Macintosh should work, as will the MacOS X
+Terminal application (although Terminal.app reportedly doesn't support 256
+colors).  The console windows for Windows NT and Windows 2000 will not
+work, as they do not even attempt to support ANSI X3.64.
+
+For a complete (to my current knowledge) compatibility list, see the
+Term::ANSIColor module documentation.  If you have any additions to the
+table in the documentation, please send them to me.
+
+The test suite requires Test::More (part of Perl since 5.6.2).  The
+following additional Perl modules will be used by the test suite if
+present:
+
+* Devel::Cover
+* Test::MinimumVersion
+* Test::Perl::Critic
+* Test::Pod
+* Test::Pod::Coverage
+* Test::Spelling
+* Test::Strict
+* Test::Synopsis
+* Test::Warn
+
+All are available on CPAN.  Those tests will be skipped if the modules are
+not available.
diff --git a/t/data/update/c-tap-harness/docknot.yaml b/t/data/update/c-tap-harness/docknot.yaml
new file mode 100644
index 0000000..88337dc
--- /dev/null
+++ b/t/data/update/c-tap-harness/docknot.yaml
@@ -0,0 +1,256 @@
+---
+blurb: |
+  C TAP Harness is a pure-C implementation of TAP, the Test Anything
+  Protocol.  TAP is the text-based protocol used by Perl's test suite.  This
+  package provides a harness similar to Perl's Test::Harness for running
+  tests, with some additional features useful for test suites in packages
+  that use Autoconf and Automake, and C and shell libraries to make writing
+  TAP-compliant test programs easier.
+build:
+  autoconf: '2.64'
+  automake: '1.11'
+  autotools: true
+  cplusplus: true
+  install: false
+  manpages: true
+  suffix: |
+    Installing C TAP Harness is not normally done.  Instead, see the section
+    on using the harness below.
+  type: Autoconf
+  valgrind: true
+copyrights:
+- holder: Russ Allbery <eagle@eyrie.org>
+  years: 2000-2001, 2004, 2006-2016
+- holder: The Board of Trustees of the Leland Stanford Junior University
+  years: 2006-2009, 2011-2013
+description: |
+  This package started as the runtests program I wrote for INN in 2000 to
+  serve as the basis for a new test suite using a test protocol similar to
+  that used for Perl modules.  When I started maintaining additional C
+  packages, I adopted runtests for the test suite driver of those as well,
+  resulting in further improvements but also separate copies of the same
+  program in different distributions.  The C TAP Harness distribution merges
+  all the various versions into a single code base that all my packages can
+  pull from.
+
+  C TAP Harness provides a full TAP specification driver (apart from a few
+  possible edge cases) and has additional special features for supporting
+  builds outside the source directory.  It's mostly useful for packages
+  using Autoconf and Automake and because it doesn't assume or require Perl.
+
+  The runtests program can be built with knowledge of the source and build
+  directory and pass that knowledge on to test scripts, and will search for
+  test scripts in both the source and build directory.  This makes it easier
+  for packages using Autoconf and Automake and supporting out-of-tree builds
+  to build some test programs, ship others, and run them all regardless of
+  what tree they're in.  It also makes it easier for test cases to find
+  their supporting files when they run.
+
+  Also included in this package are C and shell libraries that provide
+  utility functions for writing test scripts that use TAP to report results.
+  The C library also provides a variety of utility functions useful for test
+  programs running as part of an Automake-built package: finding test data
+  files, creating temporary files, reporting output from external programs
+  running in the background, and similar common problems.
+distribution:
+  section: devel
+  tarname: c-tap-harness
+  version: c-tap-harness
+docs:
+  api:
+  - name: bail
+    title: bail and sysbail
+  - name: bmalloc
+    title: bmalloc, bcalloc, brealloc, bstrdup, and bstrndup
+  - name: breallocarray
+    title: breallocarray
+  - name: diag
+    title: diag and sysdiag
+  - name: diag_file_add
+    title: diag_file_add and diag_file_remove
+  - name: is_int
+    title: is_bool, is_int, is_double, is_string, and is_hex
+  - name: ok
+    title: ok, okv, and ok_block
+  - name: plan
+    title: plan and plan_lazy
+  - name: skip
+    title: skip and skip_block
+  - name: skip_all
+    title: skip_all
+  - name: test_cleanup_register
+    title: test_cleanup_register
+  - name: test_file_path
+    title: test_file_path and test_file_path_free
+  - name: test_tmpdir
+    title: test_tmpdir and test_tmpdir_free
+  user:
+  - name: writing
+    title: Writing TAP tests
+  - name: runtests
+    title: runtests manual page
+format: v1
+license:
+  name: Expat
+maintainer: Russ Allbery <eagle@eyrie.org>
+name: C TAP Harness
+readme:
+  sections:
+  - body: |
+      C TAP Harness comes with a comprehensive test suite, which you can run
+      after building with:
+
+      ```
+          make check
+      ```
+
+      If a test fails, you can run a single test with verbose output via:
+
+      ```
+          ./runtests -b `pwd`/tests -s `pwd`/tests -o <name-of-test>
+      ```
+
+      Do this instead of running the test program directly since it will ensure
+      that necessary environment variables are set up.  You may need to change
+      the `-s` option argument if you build with a separate build directory from
+      the source directory.
+    title: Testing
+  - body: |
+      While there is an install target that installs runtests in the default
+      binary directory (`/usr/local/bin` by default) and installs the man pages,
+      one normally wouldn't install anything from this package.  Instead, the
+      code is intended to be copied into your package and refreshed from the
+      latest release of C TAP Harness for each release.
+
+      You can obviously copy the code and integrate it however works best for
+      your package and your build system.  Here's how I do it for my packages
+      as an example:
+
+      * Create a tests directory and copy tests/runtests.c into it.  Create a
+        `tests/tap` subdirectory and copy the portions of the TAP library (from
+        `tests/tap`) that I need for that package into it.  The TAP library is
+        designed to let you drop in additional source and header files for
+        additional utility functions that are useful in your package.
+
+      * Add code to my top-level `Makefile.am` (I always use a non-recursive
+        Makefile with `subdir-objects` set) to build `runtests` and the test
+        library:
+
+        ```make
+            check_PROGRAMS = tests/runtests
+            tests_runtests_CPPFLAGS = -DC_TAP_SOURCE='"$(abs_top_srcdir)/tests"' \
+                    -DC_TAP_BUILD='"$(abs_top_builddir)/tests"'
+            check_LIBRARIES = tests/tap/libtap.a
+            tests_tap_libtap_a_CPPFLAGS = -I$(abs_top_srcdir)/tests
+            tests_tap_libtap_a_SOURCES = tests/tap/basic.c tests/tap/basic.h \
+                    tests/tap/float.c tests/tap/float.h tests/tap/macros.h
+        ```
+
+        Omit `float.c` and `float.h` from the last line if your package doesn't
+        need the `is_double` function.  Building the build and source
+        directories into runtests will let `tests/runtests -o <test>` work for
+        users without requiring that they set any other variables, even if
+        they're doing an out-of-source build.
+
+        Add additional source files and headers that should go into the TAP
+        library if you added extra utility functions for your package.
+
+      * Add code to `Makefile.am` to run the test suite:
+
+        ```make
+            check-local: $(check_PROGRAMS)
+                  cd tests && ./runtests -l $(abs_top_srcdir)/tests/TESTS
+        ```
+
+        See the `Makefile.am` in this package for an example.
+
+      * List the test programs in the `tests/TESTS` file.  This should have the
+        name of the test executable with the trailing "-t" or ".t" (you can use
+        either extension as you prefer) omitted.
+
+        Test programs must be executable.
+
+        For any test programs that need to be compiled, add build rules for
+        them in `Makefile.am`, similar to:
+
+        ```make
+            tests_libtap_c_basic_LDADD = tests/tap/libtap.a
+        ```
+
+        and add them to `check_PROGRAMS`.  If you include the `float.c` add-on
+        in your libtap library, you will need to add `-lm` to the `_LDADD`
+        setting for all test programs linked against it.
+
+        A more complex example from the remctl package that needs additional
+        libraries:
+
+        ```make
+            tests_client_open_t_LDFLAGS = $(GSSAPI_LDFLAGS)
+            tests_client_open_t_LDADD = client/libremctl.la tests/tap/libtap.a \
+                    util/libutil.la $(GSSAPI_LIBS)
+        ```
+
+        If the test program doesn't need to be compiled, add it to `EXTRA_DIST`
+        so that it will be included in the distribution.
+
+      * If you have test programs written in shell, copy `tests/tap/libtap.sh`
+        the tap subdirectory of your tests directory and add it to `EXTRA_DIST`.
+        Shell programs should start with:
+
+        ```sh
+            . "${C_TAP_SOURCE}/tap/libtap.sh"
+        ```
+
+        and can then use the functions defined in the library.
+
+      * Optionally copy `docs/writing-tests` into your package somewhere, such
+        as `tests/README`, as instructions to contributors on how to write tests
+        for this framework.
+
+      If you have configuration files that the user must create to enable some
+      of the tests, conventionally they go into `tests/config`.
+
+      If you have data files that your test cases use, conventionally they go
+      into `tests/data`.  You can then find the data directory relative to the
+      `C_TAP_SOURCE` environment variable (set by `runtests`) in your test
+      program.  If you have data that's compiled or generated by Autoconf, it
+      will be relative to the `BUILD` environment variable.  Don't forget to add
+      test data to `EXTRA_DIST` as necessary.
+
+      For more TAP library add-ons, generally ones that rely on additional
+      portability code not shipped in this package or with narrower uses, see
+      [the rra-c-util
+      package](https://www.eyrie.org/~eagle/software/rra-c-util/).  There are
+      several additional TAP library add-ons in the `tests/tap` directory in
+      that package.  It's also an example of how to use this test harness in
+      another package.
+    title: Using the Harness
+requirements: |
+  C TAP Harness requires a C compiler to build.  Any ISO C89 or later C
+  compiler on a system supporting the Single UNIX Specification, version 3
+  (SUSv3) should be sufficient.  This should not be a problem on any modern
+  system.  The test suite and shell library require a Bourne-compatible
+  shell.  Outside of the test suite, C TAP Harness has no other
+  prerequisites or requirements.
+
+  To run the test suite, you will need Perl plus the Perl module Test::More,
+  which comes with Perl 5.8 or later.  The following additional Perl modules
+  will be used by the test suite if present:
+
+  * Test::Pod
+  * Test::Spelling
+
+  All are available on CPAN.  Those tests will be skipped if the modules are
+  not available.
+support:
+  email: eagle@eyrie.org
+  github: rra/c-tap-harness
+  web: https://www.eyrie.org/~eagle/software/c-tap-harness/
+synopsis: C harness for running TAP-compliant tests
+vcs:
+  browse: https://git.eyrie.org/?p=devel/c-tap-harness.git
+  github: rra/c-tap-harness
+  openhub: https://www.openhub.net/p/c-tap-harness
+  type: Git
+  url: https://git.eyrie.org/git/devel/c-tap-harness.git
+version: '4.0'
diff --git a/t/data/update/c-tap-harness/old/blurb b/t/data/update/c-tap-harness/old/blurb
new file mode 100644
index 0000000..f648587
--- /dev/null
+++ b/t/data/update/c-tap-harness/old/blurb
@@ -0,0 +1,6 @@
+C TAP Harness is a pure-C implementation of TAP, the Test Anything
+Protocol.  TAP is the text-based protocol used by Perl's test suite.  This
+package provides a harness similar to Perl's Test::Harness for running
+tests, with some additional features useful for test suites in packages
+that use Autoconf and Automake, and C and shell libraries to make writing
+TAP-compliant test programs easier.
diff --git a/t/data/update/c-tap-harness/old/build/suffix b/t/data/update/c-tap-harness/old/build/suffix
new file mode 100644
index 0000000..9abf545
--- /dev/null
+++ b/t/data/update/c-tap-harness/old/build/suffix
@@ -0,0 +1,2 @@
+Installing C TAP Harness is not normally done.  Instead, see the section
+on using the harness below.
diff --git a/t/data/update/c-tap-harness/old/description b/t/data/update/c-tap-harness/old/description
new file mode 100644
index 0000000..5cb1bef
--- /dev/null
+++ b/t/data/update/c-tap-harness/old/description
@@ -0,0 +1,28 @@
+This package started as the runtests program I wrote for INN in 2000 to
+serve as the basis for a new test suite using a test protocol similar to
+that used for Perl modules.  When I started maintaining additional C
+packages, I adopted runtests for the test suite driver of those as well,
+resulting in further improvements but also separate copies of the same
+program in different distributions.  The C TAP Harness distribution merges
+all the various versions into a single code base that all my packages can
+pull from.
+
+C TAP Harness provides a full TAP specification driver (apart from a few
+possible edge cases) and has additional special features for supporting
+builds outside the source directory.  It's mostly useful for packages
+using Autoconf and Automake and because it doesn't assume or require Perl.
+
+The runtests program can be built with knowledge of the source and build
+directory and pass that knowledge on to test scripts, and will search for
+test scripts in both the source and build directory.  This makes it easier
+for packages using Autoconf and Automake and supporting out-of-tree builds
+to build some test programs, ship others, and run them all regardless of
+what tree they're in.  It also makes it easier for test cases to find
+their supporting files when they run.
+
+Also included in this package are C and shell libraries that provide
+utility functions for writing test scripts that use TAP to report results.
+The C library also provides a variety of utility functions useful for test
+programs running as part of an Automake-built package: finding test data
+files, creating temporary files, reporting output from external programs
+running in the background, and similar common problems.
diff --git a/t/data/update/c-tap-harness/old/metadata.json b/t/data/update/c-tap-harness/old/metadata.json
new file mode 100644
index 0000000..69fa575
--- /dev/null
+++ b/t/data/update/c-tap-harness/old/metadata.json
@@ -0,0 +1,116 @@
+{
+    "name": "C TAP Harness",
+    "version": "4.0",
+    "synopsis": "C harness for running TAP-compliant tests",
+    "maintainer": "Russ Allbery <eagle@eyrie.org>",
+    "copyrights": [
+        {
+            "holder": "Russ Allbery <eagle@eyrie.org>",
+            "years": "2000-2001, 2004, 2006-2016",
+        },
+        {
+            "holder": "The Board of Trustees of the Leland Stanford Junior University",
+            "years": "2006-2009, 2011-2013",
+        },
+    ],
+    "license": "Expat",
+    "build": {
+        "autotools": true,
+        "automake": "1.11",
+        "autoconf": "2.64",
+        "cplusplus": true,
+        "install": false,
+        "manpages": true,
+        "type": "Autoconf",
+        "valgrind": true,
+    },
+    "support": {
+        "email": "eagle@eyrie.org",
+        "github": "rra/c-tap-harness",
+        "web": "https://www.eyrie.org/~eagle/software/c-tap-harness/",
+    },
+    "vcs": {
+        "type": "Git",
+        "url": "https://git.eyrie.org/git/devel/c-tap-harness.git",
+        "browse": "https://git.eyrie.org/?p=devel/c-tap-harness.git",
+        "github": "rra/c-tap-harness",
+        "openhub": "https://www.openhub.net/p/c-tap-harness",
+    },
+    "readme": {
+        "sections": [
+            { "title": "Testing" },
+            { "title": "Using the Harness" },
+        ],
+    },
+    "distribution": {
+        "section": "devel",
+        "tarname": "c-tap-harness",
+        "version": "c-tap-harness",
+    },
+    "docs": {
+        "user": [
+            {
+                "name": "writing",
+                "title": "Writing TAP tests",
+            },
+            {
+                "name": "runtests",
+                "title": "runtests manual page",
+            },
+        ],
+        "api": [
+            {
+                "name": "bail",
+                "title": "bail and sysbail",
+            },
+            {
+                "name": "bmalloc",
+                "title": "bmalloc, bcalloc, brealloc, bstrdup, and bstrndup",
+            },
+            {
+                "name": "breallocarray",
+                "title": "breallocarray",
+            },
+            {
+                "name": "diag",
+                "title": "diag and sysdiag",
+            },
+            {
+                "name": "diag_file_add",
+                "title": "diag_file_add and diag_file_remove",
+            },
+            {
+                "name": "is_int",
+                "title": "is_bool, is_int, is_double, is_string, and is_hex",
+            },
+            {
+                "name": "ok",
+                "title": "ok, okv, and ok_block",
+            },
+            {
+                "name": "plan",
+                "title": "plan and plan_lazy",
+            },
+            {
+                "name": "skip",
+                "title": "skip and skip_block",
+            },
+            {
+                "name": "skip_all",
+                "title": "skip_all",
+            },
+            {
+                "name": "test_cleanup_register",
+                "title": "test_cleanup_register",
+            },
+            {
+                "name": "test_file_path",
+                "title": "test_file_path and test_file_path_free",
+            },
+            {
+                "name": "test_tmpdir",
+                "title": "test_tmpdir and test_tmpdir_free",
+            },
+        ],
+    },
+}
diff --git a/t/data/update/c-tap-harness/old/requirements b/t/data/update/c-tap-harness/old/requirements
new file mode 100644
index 0000000..54ddb22
--- /dev/null
+++ b/t/data/update/c-tap-harness/old/requirements
@@ -0,0 +1,16 @@
+C TAP Harness requires a C compiler to build.  Any ISO C89 or later C
+compiler on a system supporting the Single UNIX Specification, version 3
+(SUSv3) should be sufficient.  This should not be a problem on any modern
+system.  The test suite and shell library require a Bourne-compatible
+shell.  Outside of the test suite, C TAP Harness has no other
+prerequisites or requirements.
+
+To run the test suite, you will need Perl plus the Perl module Test::More,
+which comes with Perl 5.8 or later.  The following additional Perl modules
+will be used by the test suite if present:
+
+* Test::Pod
+* Test::Spelling
+
+All are available on CPAN.  Those tests will be skipped if the modules are
+not available.
diff --git a/t/data/update/c-tap-harness/old/sections/testing b/t/data/update/c-tap-harness/old/sections/testing
new file mode 100644
index 0000000..5e09e34
--- /dev/null
+++ b/t/data/update/c-tap-harness/old/sections/testing
@@ -0,0 +1,17 @@
+C TAP Harness comes with a comprehensive test suite, which you can run
+after building with:
+
+```
+    make check
+```
+
+If a test fails, you can run a single test with verbose output via:
+
+```
+    ./runtests -b `pwd`/tests -s `pwd`/tests -o <name-of-test>
+```
+
+Do this instead of running the test program directly since it will ensure
+that necessary environment variables are set up.  You may need to change
+the `-s` option argument if you build with a separate build directory from
+the source directory.
diff --git a/t/data/update/c-tap-harness/old/sections/using-the-harness b/t/data/update/c-tap-harness/old/sections/using-the-harness
new file mode 100644
index 0000000..bf61cca
--- /dev/null
+++ b/t/data/update/c-tap-harness/old/sections/using-the-harness
@@ -0,0 +1,108 @@
+While there is an install target that installs runtests in the default
+binary directory (`/usr/local/bin` by default) and installs the man pages,
+one normally wouldn't install anything from this package.  Instead, the
+code is intended to be copied into your package and refreshed from the
+latest release of C TAP Harness for each release.
+
+You can obviously copy the code and integrate it however works best for
+your package and your build system.  Here's how I do it for my packages
+as an example:
+
+* Create a tests directory and copy tests/runtests.c into it.  Create a
+  `tests/tap` subdirectory and copy the portions of the TAP library (from
+  `tests/tap`) that I need for that package into it.  The TAP library is
+  designed to let you drop in additional source and header files for
+  additional utility functions that are useful in your package.
+
+* Add code to my top-level `Makefile.am` (I always use a non-recursive
+  Makefile with `subdir-objects` set) to build `runtests` and the test
+  library:
+
+  ```make
+      check_PROGRAMS = tests/runtests
+      tests_runtests_CPPFLAGS = -DC_TAP_SOURCE='"$(abs_top_srcdir)/tests"' \
+              -DC_TAP_BUILD='"$(abs_top_builddir)/tests"'
+      check_LIBRARIES = tests/tap/libtap.a
+      tests_tap_libtap_a_CPPFLAGS = -I$(abs_top_srcdir)/tests
+      tests_tap_libtap_a_SOURCES = tests/tap/basic.c tests/tap/basic.h \
+              tests/tap/float.c tests/tap/float.h tests/tap/macros.h
+  ```
+
+  Omit `float.c` and `float.h` from the last line if your package doesn't
+  need the `is_double` function.  Building the build and source
+  directories into runtests will let `tests/runtests -o <test>` work for
+  users without requiring that they set any other variables, even if
+  they're doing an out-of-source build.
+
+  Add additional source files and headers that should go into the TAP
+  library if you added extra utility functions for your package.
+
+* Add code to `Makefile.am` to run the test suite:
+
+  ```make
+      check-local: $(check_PROGRAMS)
+            cd tests && ./runtests -l $(abs_top_srcdir)/tests/TESTS
+  ```
+
+  See the `Makefile.am` in this package for an example.
+
+* List the test programs in the `tests/TESTS` file.  This should have the
+  name of the test executable with the trailing "-t" or ".t" (you can use
+  either extension as you prefer) omitted.
+
+  Test programs must be executable.
+
+  For any test programs that need to be compiled, add build rules for
+  them in `Makefile.am`, similar to:
+
+  ```make
+      tests_libtap_c_basic_LDADD = tests/tap/libtap.a
+  ```
+
+  and add them to `check_PROGRAMS`.  If you include the `float.c` add-on
+  in your libtap library, you will need to add `-lm` to the `_LDADD`
+  setting for all test programs linked against it.
+
+  A more complex example from the remctl package that needs additional
+  libraries:
+
+  ```make
+      tests_client_open_t_LDFLAGS = $(GSSAPI_LDFLAGS)
+      tests_client_open_t_LDADD = client/libremctl.la tests/tap/libtap.a \
+              util/libutil.la $(GSSAPI_LIBS)
+  ```
+
+  If the test program doesn't need to be compiled, add it to `EXTRA_DIST`
+  so that it will be included in the distribution.
+
+* If you have test programs written in shell, copy `tests/tap/libtap.sh`
+  the tap subdirectory of your tests directory and add it to `EXTRA_DIST`.
+  Shell programs should start with:
+
+  ```sh
+      . "${C_TAP_SOURCE}/tap/libtap.sh"
+  ```
+
+  and can then use the functions defined in the library.
+
+* Optionally copy `docs/writing-tests` into your package somewhere, such
+  as `tests/README`, as instructions to contributors on how to write tests
+  for this framework.
+
+If you have configuration files that the user must create to enable some
+of the tests, conventionally they go into `tests/config`.
+
+If you have data files that your test cases use, conventionally they go
+into `tests/data`.  You can then find the data directory relative to the
+`C_TAP_SOURCE` environment variable (set by `runtests`) in your test
+program.  If you have data that's compiled or generated by Autoconf, it
+will be relative to the `BUILD` environment variable.  Don't forget to add
+test data to `EXTRA_DIST` as necessary.
+
+For more TAP library add-ons, generally ones that rely on additional
+portability code not shipped in this package or with narrower uses, see
+[the rra-c-util
+package](https://www.eyrie.org/~eagle/software/rra-c-util/).  There are
+several additional TAP library add-ons in the `tests/tap` directory in
+that package.  It's also an example of how to use this test harness in
+another package.
diff --git a/t/data/update/control-archive/docknot.yaml b/t/data/update/control-archive/docknot.yaml
new file mode 100644
index 0000000..4508720
--- /dev/null
+++ b/t/data/update/control-archive/docknot.yaml
@@ -0,0 +1,322 @@
+---
+blurb: |
+  This software generates an INN control.ctl configuration file from
+  hierarchy configuration fragments, verifies control messages using GnuPG
+  where possible, processes new control messages to update a newsgroup list,
+  archives new control messages, and exports the list of newsgroups in a
+  format suitable for synchronizing the newsgroup list of a Netnews news
+  server.  It is the software that maintains the control message and
+  newsgroup lists available from ftp.isc.org.
+build:
+  install: false
+  type: make
+copyrights:
+- holder: Russ Allbery <eagle@eyrie.org>
+  years: 2002-2004, 2007-2014, 2016-2018
+- holder: Marco d'Itri
+  years: '2001'
+- holder: UUNET Technologies, Inc.
+  years: '1996'
+description: |
+  This package contains three major components:
+
+  * All of the configuration used to generate a `control.ctl` file for INN
+    and the `PGPKEYS` and `README.html` files distributed with pgpcontrol,
+    along with the script to generate those files.
+
+  * Software to process control messages, verify them against that
+    authorization information, and maintain a control message archive and
+    list of active newsgroups.  Software is also included to generate
+    reports of recent changes to the list of active newsgroups.
+
+  * The documentation files included in the control message archive and
+    newsgroup lists on ftp.isc.org.
+
+  Manual changes to the canonical newsgroup list are supported in a way that
+  generates the same log messages and uses the same locking structure so
+  that they can co-exist with automated changes and be included in the same
+  reports.
+
+  This is the software that generates the [active newsgroup
+  lists](ftp://ftp.isc.org/pub/usenet/CONFIG/) and [control message
+  archive](ftp://ftp.isc.org/pub/usenet/control/) hosted on ftp.isc.org, and
+  the source of the `control.ctl` file provided with INN.
+
+  For a web presentation of the information recorded here, as well as other
+  useful information about Usenet hierarchies, please see the [list of
+  Usenet managed hierarchies](http://usenet.trigofacile.com/hierarchies/).
+distribution:
+  section: usenet
+  tarname: control-archive
+  version: control-archive
+docs:
+  user:
+  - name: control-summary
+    title: control-summary manual page
+  - name: export-control
+    title: export-control manual page
+  - name: generate-files
+    title: generate-files manual page
+  - name: process-control
+    title: process-control manual page
+  - name: update-control
+    title: update-control manual page
+format: v1
+license:
+  name: Expat
+  notices: |
+    This product includes software developed by UUNET Technologies, Inc.
+maintainer: Russ Allbery <eagle@eyrie.org>
+name: control-archive
+quote:
+  author: Gene Spafford
+  text: |
+    Usenet is like a herd of performing elephants with diarrhea — massive,
+    difficult to redirect, awe-inspiring, entertaining, and a source of
+    mind-boggling amounts of excrement when you least expect it.
+readme:
+  sections:
+  - body: |
+      This package uses a three-part version number.  The first number will be
+      incremented for major changes, major new functionality, incompatible
+      changes to the configuration format (more than just adding new keys), or
+      similar disruptive changes.  For lesser changes, the second number will be
+      incremented for any change to the code or functioning of the software.  A
+      change to the third part of the version number indicates a release with
+      changes only to the configuration, PGP keys, and documentation files.
+    title: Versioning
+  - body: |
+      The configuration data is in one file per hierarchy in the `config`
+      directory.  Each file has the format specified in FORMAT and is designed
+      to be readable by INN's new configuration parser in case this can be
+      further automated down the road.  The `config/special` directory contains
+      overrides, raw `control.ctl` fragments that should be used for particular
+      hierarchies instead of automatically-generated entries (usually for
+      special comments).  Eventually, the format should be extended to handle as
+      many of these cases as possible.
+
+      The `keys` directory contains the PGP public keys for every hierarchy that
+      has one.  The user IDs on these keys must match the signer expected by the
+      configuration data for the corresponding hierarchy.
+
+      The `forms` directory contains the basic file structure for the three
+      generated files.
+
+      The `scripts` directory contains all the software that generates the
+      configuration and documentation files, processes control messages, updates
+      the database, creates the newsgroup lists, and generates reports.  Most
+      scripts in that directory have POD documentation included at the end of
+      the script, viewable by running perldoc on the script.
+
+      The `templates` directory contains templates for the `control-summary`
+      script.  These are the templates I use myself.  Other installations should
+      customize them.
+
+      The `docs` directory contains the extra documentation files that are
+      distributed from ftp.isc.org in the control message archive and newsgroup
+      list directories, plus the DocKnot metadata for this package.
+    title: Layout
+  - body: |
+      This software is set up to run from `/srv/control`.  To use a different
+      location, edit the paths at the beginning of each of the scripts in the
+      `scripts` directory to use different paths.  By default, copying all the
+      files from the distribution into a `/srv/control` directory is almost all
+      that's needed.  An install rule is provided to do this.  To install the
+      software, run:
+
+      ```sh
+          make install
+      ```
+
+      You will need write access to `/srv/control` or permission to create it.
+
+      `process-control` and `generate-files` need a GnuPG keyring containing all
+      of the honored hierarchy keys.  To generate this keyring, run `make
+      install` or:
+
+      ```sh
+          mkdir keyring
+          gpg --homedir=keyring --allow-non-selfsigned-uid --import keys/*
+      ```
+
+      from the top level of this distribution.  `process-control` also expects a
+      `control.ctl` file in `/srv/control/control.ctl`, which can be generated
+      from the files included here (after creating the keyring as described
+      above) by running `make install` or:
+
+      ```sh
+          scripts/generate-files
+      ```
+
+      Both of these are done automatically as part of `make install`.
+      process-control expects `/srv/control/archive` to exist and archives
+      control messages there.  It expects `/srv/control/tmp` to exist and uses
+      it for temporary files for GnuPG control message verification.
+
+      To process incoming control messages, you need to run `process-control` on
+      each message.  `process-control` expects to receive, on standard input,
+      lines consisting of a path to a file, a space, and a message ID.  This
+      input format is designed to work with the tinyleaf server that comes with
+      INN 2.5 and later, but it should also work as a channel feed from
+      pre-storage-API versions of INN (1.x).  It will not work without
+      modification via a channel feed from a current version of INN, since it
+      doesn't understand the storage API and doesn't know how to retrieve
+      articles by tokens.  This could be easily added; I just haven't needed it.
+
+      If you're using tinyleaf, here is the setup process:
+
+      1. Create a directory that tinyleaf will use to store incoming articles
+         temporarily, the archive directory, and the logs directory and
+         install the software:
+
+         ```sh
+             make install
+         ```
+
+      2. Run tinyleaf on some port, configuring it to use that directory and
+         to run process-control.  A typical tinyleaf command line would be:
+
+         ```sh
+             tinyleaf /srv/control/spool /srv/control/scripts/process-control
+         ```
+
+         I run tinyleaf using systemd, but any inetd implementation should work
+         equally well.
+
+      3. Set up a news feed to the system running tinyleaf that sends control
+         messages of interest.  You should be careful not to send cancel control
+         messages or you'll get a ton of junk in your logs.  The INN newsfeeds
+         entry I use is:
+
+         ```
+             isc-control:control,control.*,!control.cancel:Tf,Wnm:
+         ```
+
+         combined with nntpsend to send the articles.
+
+      That should be all there is to it.  Watch the logs directory to see what
+      happens for incoming messages.
+
+      `scripts/process-control` just maintains a database file.  To export that
+      data in a format that's useful for other software, run
+      `scripts/export-control`.  This expects a `/srv/control/export` directory
+      into which it stores active and newsgroups files, a copy of the
+      `control.ctl` file, and all of the logs in a `LOGS` subdirectory.  This
+      export directory can then be made available on the web, copied to another
+      system, or whatever else is appropriate.  Generally,
+      `scripts/export-control` should be run periodically from cron.
+
+      Reports can be generated using `scripts/control-summary`.  This script
+      needs configuration before running; see the top of the script and its
+      included POD documentation.  There is a sample template in the `templates`
+      directory, and `scripts/weekly-report` shows a sample cron job for sending
+      out a regular report.
+    title: Installation
+  - body: |
+      This package is intended to provide all of the tools, configuration, and
+      information required to duplicate the ftp.isc.org control message archive
+      and newsgroup list service if you so desire.  To set up a similar service
+      based on that service, however, you will also want to bootstrap from the
+      existing data.  Here is the procedure for that:
+
+      1. Be sure that you're starting from the latest software and set of
+         configuration files.  I will generally try to make a new release after
+         committing a batch of changes, but I may not make a new release after
+         every change.  See the sections below for information about the Git
+         repository in which this package is maintained.  You can always clone
+         that repository to get the latest configuration (and then merge or
+         cherry-pick changes from my repository into your repository as you
+         desire).
+
+      2. Download the current newsgroup list from:
+
+             ftp://ftp.isc.org/pub/usenet/CONFIG/newsgroups.bz2
+
+         and then bootstrap the database from it:
+
+         ```sh
+             bzip2 -dc newsgroups.bz2 | scripts/update-control bulkload
+         ```
+
+      3. If you want the log information so that your reports will include
+         changes made in the ftp.isc.org archive before you created your own,
+         copy the contents of ftp://ftp.isc.org/pub/usenet/CONFIG/LOGS/ into
+         `/srv/control/logs`.
+
+      4. If you want to start with the existing control message repository,
+         download the contents of ftp://ftp.isc.org/pub/usenet/control/ into
+         `/srv/control/archive`.  You can do this using a recursive download
+         tool that understands FTP, such as wget, but please use the options
+         that add delays and don't hammer the server to death.
+
+      After finishing those steps, you will have a copy of the ftp.isc.org
+      archive and can start processing control messages, possibly with different
+      configuration choices.  You can generate the files that are found in
+      ftp://ftp.isc.org/pub/usenet/CONFIG/ by running `scripts/export-control`
+      as described above.
+    title: Bootstrapping
+  - body: |
+      To add a new hierarchy, add a configuration fragment in the `config`
+      directory named after the hierarchy, following the format of the existing
+      files, and run `scripts/generate-files` to create a new `control.ctl`
+      file.  See the documentation in `scripts/generate-files` for details about
+      the supported configuration keys.
+
+      If the hierarchy uses PGP-signed control messages, also put the PGP key
+      into the `keys` directory in a file named after the hierarchy.  Then, run:
+
+      ```sh
+          gpg --homedir=keyring --import keys/<hierarchy>
+      ```
+
+      to add the new key to the working keyring.
+
+      The first user ID on the key must match the signer expected by the
+      configuration data for the corresponding hierarchy.  If a hierarchy
+      administrator sets that up wrong (usually by putting additional key IDs on
+      the key), this can be corrected by importing the key into a keyring with
+      GnuPG, using `gpg --edit-key` to remove the offending user ID, and
+      exporting the key again with `gpg --export --ascii`.
+
+      When adding a new hierarchy, it's often useful to bootstrap the newsgroup
+      list by importing the current checkgroups.  To do this, obtain the
+      checkgroups as a text file (containing only the groups without any news
+      headers) and run:
+
+      ```sh
+          scripts/update-control checkgroups <hierarchy> < <checkgroups>
+      ```
+
+      where <hierarchy> is the hierarchy the checkgroups is for and
+      <checkgroups> is the path to the checkgroups file.
+    title: Maintenance
+requirements: |
+  Perl 5.6 or later plus the following additional Perl modules are required:
+
+  * Compress::Zlib (included in Perl 5.10 and later)
+  * Date::Parse (part of TimeDate)
+  * Net::NNTP (included in Perl 5.8 and later)
+  * Text::Template
+
+  [gzip](https://www.gnu.org/software/gzip/) and
+  [bzip2](http://www.bzip.org/) are required.  Both are generally available
+  with current operating systems, possibly as supplemental packages.
+
+  process-control expects to be fed file names and message IDs of control
+  messages on standard input and therefore needs to be run from a news
+  server or some other source of control messages.  A minimalist news server
+  like tinyleaf is suitable for this (I wrote tinyleaf, available as part of
+  [INN](https://www.eyrie.org/~eagle/software/inn/), for this purpose).
+support:
+  email: eagle@eyrie.org
+  extra: |
+    Configuration updates should be sent to usenet-config@isc.org.
+  github: rra/control-archive
+  web: https://www.eyrie.org/~eagle/software/control-archive/
+synopsis: processing and archiving of Netnews control messages
+vcs:
+  browse: https://git.eyrie.org/?p=usenet/control.archive.git
+  github: rra/control-archive
+  type: Git
+  url: https://git.eyrie.org/git/usenet/control-archive.git
+version: 1.8.0
diff --git a/t/data/update/control-archive/old/blurb b/t/data/update/control-archive/old/blurb
new file mode 100644
index 0000000..19b415b
--- /dev/null
+++ b/t/data/update/control-archive/old/blurb
@@ -0,0 +1,7 @@
+This software generates an INN control.ctl configuration file from
+hierarchy configuration fragments, verifies control messages using GnuPG
+where possible, processes new control messages to update a newsgroup list,
+archives new control messages, and exports the list of newsgroups in a
+format suitable for synchronizing the newsgroup list of a Netnews news
+server.  It is the software that maintains the control message and
+newsgroup lists available from ftp.isc.org.
diff --git a/t/data/update/control-archive/old/description b/t/data/update/control-archive/old/description
new file mode 100644
index 0000000..b6170d0
--- /dev/null
+++ b/t/data/update/control-archive/old/description
@@ -0,0 +1,27 @@
+This package contains three major components:
+
+* All of the configuration used to generate a `control.ctl` file for INN
+  and the `PGPKEYS` and `README.html` files distributed with pgpcontrol,
+  along with the script to generate those files.
+
+* Software to process control messages, verify them against that
+  authorization information, and maintain a control message archive and
+  list of active newsgroups.  Software is also included to generate
+  reports of recent changes to the list of active newsgroups.
+
+* The documentation files included in the control message archive and
+  newsgroup lists on ftp.isc.org.
+
+Manual changes to the canonical newsgroup list are supported in a way that
+generates the same log messages and uses the same locking structure so
+that they can co-exist with automated changes and be included in the same
+reports.
+
+This is the software that generates the [active newsgroup
+lists](ftp://ftp.isc.org/pub/usenet/CONFIG/) and [control message
+archive](ftp://ftp.isc.org/pub/usenet/control/) hosted on ftp.isc.org, and
+the source of the `control.ctl` file provided with INN.
+
+For a web presentation of the information recorded here, as well as other
+useful information about Usenet hierarchies, please see the [list of
+Usenet managed hierarchies](http://usenet.trigofacile.com/hierarchies/).
diff --git a/t/data/update/control-archive/old/metadata.json b/t/data/update/control-archive/old/metadata.json
new file mode 100644
index 0000000..dd20003
--- /dev/null
+++ b/t/data/update/control-archive/old/metadata.json
@@ -0,0 +1,77 @@
+{
+    "name": "control-archive",
+    "version": "1.8.0",
+    "synopsis": "processing and archiving of Netnews control messages",
+    "maintainer": "Russ Allbery <eagle@eyrie.org>",
+    "copyrights": [
+        {
+            "holder": "Russ Allbery <eagle@eyrie.org>",
+            "years": "2002-2004, 2007-2014, 2016-2018",
+        },
+        {
+            "holder": "Marco d'Itri",
+            "years": "2001",
+        },
+        {
+            "holder": "UUNET Technologies, Inc.",
+            "years": "1996",
+        }
+    ],
+    "license": "Expat",
+    "build": {
+        "install": false,
+        "type": "make",
+    },
+    "support": {
+        "email": "eagle@eyrie.org",
+        "github": "rra/control-archive",
+        "web": "https://www.eyrie.org/~eagle/software/control-archive/",
+    },
+    "vcs": {
+        "type": "Git",
+        "url": "https://git.eyrie.org/git/usenet/control-archive.git",
+        "browse": "https://git.eyrie.org/?p=usenet/control.archive.git",
+        "github": "rra/control-archive",
+    },
+    "readme": {
+        "sections": [
+            { "title": "Versioning" },
+            { "title": "Layout" },
+            { "title": "Installation" },
+            { "title": "Bootstrapping" },
+            { "title": "Maintenance" },
+        ],
+    },
+    "quote": {
+        "author": "Gene Spafford",
+    },
+    "distribution": {
+        "section": "usenet",
+        "tarname": "control-archive",
+        "version": "control-archive",
+    },
+    "docs": {
+        "user": [
+            {
+                "name": "control-summary",
+                "title": "control-summary manual page",
+            },
+            {
+                "name": "export-control",
+                "title": "export-control manual page",
+            },
+            {
+                "name": "generate-files",
+                "title": "generate-files manual page",
+            },
+            {
+                "name": "process-control",
+                "title": "process-control manual page",
+            },
+            {
+                "name": "update-control",
+                "title": "update-control manual page",
+            },
+        ],
+    },
+}
diff --git a/t/data/update/control-archive/old/notices b/t/data/update/control-archive/old/notices
new file mode 100644
index 0000000..d808155
--- /dev/null
+++ b/t/data/update/control-archive/old/notices
@@ -0,0 +1 @@
+This product includes software developed by UUNET Technologies, Inc.
diff --git a/t/data/update/control-archive/old/quote b/t/data/update/control-archive/old/quote
new file mode 100644
index 0000000..1ac4393
--- /dev/null
+++ b/t/data/update/control-archive/old/quote
@@ -0,0 +1,3 @@
+Usenet is like a herd of performing elephants with diarrhea — massive,
+difficult to redirect, awe-inspiring, entertaining, and a source of
+mind-boggling amounts of excrement when you least expect it.
diff --git a/t/data/update/control-archive/old/requirements b/t/data/update/control-archive/old/requirements
new file mode 100644
index 0000000..2b21515
--- /dev/null
+++ b/t/data/update/control-archive/old/requirements
@@ -0,0 +1,16 @@
+Perl 5.6 or later plus the following additional Perl modules are required:
+
+* Compress::Zlib (included in Perl 5.10 and later)
+* Date::Parse (part of TimeDate)
+* Net::NNTP (included in Perl 5.8 and later)
+* Text::Template
+
+[gzip](https://www.gnu.org/software/gzip/) and
+[bzip2](http://www.bzip.org/) are required.  Both are generally available
+with current operating systems, possibly as supplemental packages.
+
+process-control expects to be fed file names and message IDs of control
+messages on standard input and therefore needs to be run from a news
+server or some other source of control messages.  A minimalist news server
+like tinyleaf is suitable for this (I wrote tinyleaf, available as part of
+[INN](https://www.eyrie.org/~eagle/software/inn/), for this purpose).
diff --git a/t/data/update/control-archive/old/sections/bootstrapping b/t/data/update/control-archive/old/sections/bootstrapping
new file mode 100644
index 0000000..7063e23
--- /dev/null
+++ b/t/data/update/control-archive/old/sections/bootstrapping
@@ -0,0 +1,41 @@
+This package is intended to provide all of the tools, configuration, and
+information required to duplicate the ftp.isc.org control message archive
+and newsgroup list service if you so desire.  To set up a similar service
+based on that service, however, you will also want to bootstrap from the
+existing data.  Here is the procedure for that:
+
+1. Be sure that you're starting from the latest software and set of
+   configuration files.  I will generally try to make a new release after
+   committing a batch of changes, but I may not make a new release after
+   every change.  See the sections below for information about the Git
+   repository in which this package is maintained.  You can always clone
+   that repository to get the latest configuration (and then merge or
+   cherry-pick changes from my repository into your repository as you
+   desire).
+
+2. Download the current newsgroup list from:
+
+       ftp://ftp.isc.org/pub/usenet/CONFIG/newsgroups.bz2
+
+   and then bootstrap the database from it:
+
+   ```sh
+       bzip2 -dc newsgroups.bz2 | scripts/update-control bulkload
+   ```
+
+3. If you want the log information so that your reports will include
+   changes made in the ftp.isc.org archive before you created your own,
+   copy the contents of ftp://ftp.isc.org/pub/usenet/CONFIG/LOGS/ into
+   `/srv/control/logs`.
+
+4. If you want to start with the existing control message repository,
+   download the contents of ftp://ftp.isc.org/pub/usenet/control/ into
+   `/srv/control/archive`.  You can do this using a recursive download
+   tool that understands FTP, such as wget, but please use the options
+   that add delays and don't hammer the server to death.
+
+After finishing those steps, you will have a copy of the ftp.isc.org
+archive and can start processing control messages, possibly with different
+configuration choices.  You can generate the files that are found in
+ftp://ftp.isc.org/pub/usenet/CONFIG/ by running `scripts/export-control`
+as described above.
diff --git a/t/data/update/control-archive/old/sections/installation b/t/data/update/control-archive/old/sections/installation
new file mode 100644
index 0000000..a162011
--- /dev/null
+++ b/t/data/update/control-archive/old/sections/installation
@@ -0,0 +1,94 @@
+This software is set up to run from `/srv/control`.  To use a different
+location, edit the paths at the beginning of each of the scripts in the
+`scripts` directory to use different paths.  By default, copying all the
+files from the distribution into a `/srv/control` directory is almost all
+that's needed.  An install rule is provided to do this.  To install the
+software, run:
+
+```sh
+    make install
+```
+
+You will need write access to `/srv/control` or permission to create it.
+
+`process-control` and `generate-files` need a GnuPG keyring containing all
+of the honored hierarchy keys.  To generate this keyring, run `make
+install` or:
+
+```sh
+    mkdir keyring
+    gpg --homedir=keyring --allow-non-selfsigned-uid --import keys/*
+```
+
+from the top level of this distribution.  `process-control` also expects a
+`control.ctl` file in `/srv/control/control.ctl`, which can be generated
+from the files included here (after creating the keyring as described
+above) by running `make install` or:
+
+```sh
+    scripts/generate-files
+```
+
+Both of these are done automatically as part of `make install`.
+process-control expects `/srv/control/archive` to exist and archives
+control messages there.  It expects `/srv/control/tmp` to exist and uses
+it for temporary files for GnuPG control message verification.
+
+To process incoming control messages, you need to run `process-control` on
+each message.  `process-control` expects to receive, on standard input,
+lines consisting of a path to a file, a space, and a message ID.  This
+input format is designed to work with the tinyleaf server that comes with
+INN 2.5 and later, but it should also work as a channel feed from
+pre-storage-API versions of INN (1.x).  It will not work without
+modification via a channel feed from a current version of INN, since it
+doesn't understand the storage API and doesn't know how to retrieve
+articles by tokens.  This could be easily added; I just haven't needed it.
+
+If you're using tinyleaf, here is the setup process:
+
+1. Create a directory that tinyleaf will use to store incoming articles
+   temporarily, the archive directory, and the logs directory and
+   install the software:
+
+   ```sh
+       make install
+   ```
+
+2. Run tinyleaf on some port, configuring it to use that directory and
+   to run process-control.  A typical tinyleaf command line would be:
+
+   ```sh
+       tinyleaf /srv/control/spool /srv/control/scripts/process-control
+   ```
+
+   I run tinyleaf using systemd, but any inetd implementation should work
+   equally well.
+
+3. Set up a news feed to the system running tinyleaf that sends control
+   messages of interest.  You should be careful not to send cancel control
+   messages or you'll get a ton of junk in your logs.  The INN newsfeeds
+   entry I use is:
+
+   ```
+       isc-control:control,control.*,!control.cancel:Tf,Wnm:
+   ```
+
+   combined with nntpsend to send the articles.
+
+That should be all there is to it.  Watch the logs directory to see what
+happens for incoming messages.
+
+`scripts/process-control` just maintains a database file.  To export that
+data in a format that's useful for other software, run
+`scripts/export-control`.  This expects a `/srv/control/export` directory
+into which it stores active and newsgroups files, a copy of the
+`control.ctl` file, and all of the logs in a `LOGS` subdirectory.  This
+export directory can then be made available on the web, copied to another
+system, or whatever else is appropriate.  Generally,
+`scripts/export-control` should be run periodically from cron.
+
+Reports can be generated using `scripts/control-summary`.  This script
+needs configuration before running; see the top of the script and its
+included POD documentation.  There is a sample template in the `templates`
+directory, and `scripts/weekly-report` shows a sample cron job for sending
+out a regular report.
diff --git a/t/data/update/control-archive/old/sections/layout b/t/data/update/control-archive/old/sections/layout
new file mode 100644
index 0000000..d12d7e1
--- /dev/null
+++ b/t/data/update/control-archive/old/sections/layout
@@ -0,0 +1,29 @@
+The configuration data is in one file per hierarchy in the `config`
+directory.  Each file has the format specified in FORMAT and is designed
+to be readable by INN's new configuration parser in case this can be
+further automated down the road.  The `config/special` directory contains
+overrides, raw `control.ctl` fragments that should be used for particular
+hierarchies instead of automatically-generated entries (usually for
+special comments).  Eventually, the format should be extended to handle as
+many of these cases as possible.
+
+The `keys` directory contains the PGP public keys for every hierarchy that
+has one.  The user IDs on these keys must match the signer expected by the
+configuration data for the corresponding hierarchy.
+
+The `forms` directory contains the basic file structure for the three
+generated files.
+
+The `scripts` directory contains all the software that generates the
+configuration and documentation files, processes control messages, updates
+the database, creates the newsgroup lists, and generates reports.  Most
+scripts in that directory have POD documentation included at the end of
+the script, viewable by running perldoc on the script.
+
+The `templates` directory contains templates for the `control-summary`
+script.  These are the templates I use myself.  Other installations should
+customize them.
+
+The `docs` directory contains the extra documentation files that are
+distributed from ftp.isc.org in the control message archive and newsgroup
+list directories, plus the DocKnot metadata for this package.
diff --git a/t/data/update/control-archive/old/sections/maintenance b/t/data/update/control-archive/old/sections/maintenance
new file mode 100644
index 0000000..676a6f7
--- /dev/null
+++ b/t/data/update/control-archive/old/sections/maintenance
@@ -0,0 +1,33 @@
+To add a new hierarchy, add a configuration fragment in the `config`
+directory named after the hierarchy, following the format of the existing
+files, and run `scripts/generate-files` to create a new `control.ctl`
+file.  See the documentation in `scripts/generate-files` for details about
+the supported configuration keys.
+
+If the hierarchy uses PGP-signed control messages, also put the PGP key
+into the `keys` directory in a file named after the hierarchy.  Then, run:
+
+```sh
+    gpg --homedir=keyring --import keys/<hierarchy>
+```
+
+to add the new key to the working keyring.
+
+The first user ID on the key must match the signer expected by the
+configuration data for the corresponding hierarchy.  If a hierarchy
+administrator sets that up wrong (usually by putting additional key IDs on
+the key), this can be corrected by importing the key into a keyring with
+GnuPG, using `gpg --edit-key` to remove the offending user ID, and
+exporting the key again with `gpg --export --ascii`.
+
+When adding a new hierarchy, it's often useful to bootstrap the newsgroup
+list by importing the current checkgroups.  To do this, obtain the
+checkgroups as a text file (containing only the groups without any news
+headers) and run:
+
+```sh
+    scripts/update-control checkgroups <hierarchy> < <checkgroups>
+```
+
+where <hierarchy> is the hierarchy the checkgroups is for and
+<checkgroups> is the path to the checkgroups file.
diff --git a/t/data/update/control-archive/old/sections/versioning b/t/data/update/control-archive/old/sections/versioning
new file mode 100644
index 0000000..7326aeb
--- /dev/null
+++ b/t/data/update/control-archive/old/sections/versioning
@@ -0,0 +1,7 @@
+This package uses a three-part version number.  The first number will be
+incremented for major changes, major new functionality, incompatible
+changes to the configuration format (more than just adding new keys), or
+similar disruptive changes.  For lesser changes, the second number will be
+incremented for any change to the code or functioning of the software.  A
+change to the third part of the version number indicates a release with
+changes only to the configuration, PGP keys, and documentation files.
diff --git a/t/data/update/control-archive/old/support/extra b/t/data/update/control-archive/old/support/extra
new file mode 100644
index 0000000..082b244
--- /dev/null
+++ b/t/data/update/control-archive/old/support/extra
@@ -0,0 +1 @@
+Configuration updates should be sent to usenet-config@isc.org.
diff --git a/t/data/update/lbcd/docknot.yaml b/t/data/update/lbcd/docknot.yaml
new file mode 100644
index 0000000..3ee5145
--- /dev/null
+++ b/t/data/update/lbcd/docknot.yaml
@@ -0,0 +1,113 @@
+---
+blurb: |
+  lbcd is a daemon that runs on a UNIX system and answers UDP queries with
+  information about system load, number of logged-on users, uptime, and free
+  /tmp space.  This information can be used to accumulate system status
+  across a cluster with light-weight queries or can be used as input to a
+  load-balancing system to choose the best system to which to direct new
+  incoming connections.
+build:
+  autoconf: '2.64'
+  automake: '1.11'
+  autotools: true
+  lancaster: true
+  middle: |
+    lbcd looks for `$sysconfdir/nolbcd` and returns the maximum load if that
+    file is present, allowing one to effectively drop a system out of a
+    load-balanced pool by touching that file.  By default, the path is
+    `/usr/local/etc/nolbcd`, but you may want to pass `--sysconfdir=/etc` to
+    configure to use `/etc/nolbcd`.
+
+    lbcdclient is written in Perl, so you may have to edit the first line of
+    the script to point to the correct Perl location on your system.  It does
+    not use any sophisticated Perl features or add-on modules.
+  suffix: |
+    You will generally want to start lbcd at system boot.  All that is needed
+    is a simple init script to start lbcd with the appropriate options or kill
+    it again.  It writes its PID into `/var/run/lbcd.pid` by default (and this
+    can be changed with the `-P` option).  On many systems, lbcd will need to
+    run as root or as a member of particular groups to obtain system load
+    average and uptime information.
+  type: Autoconf
+copyrights:
+- holder: The Board of Trustees of the Leland Stanford Junior University
+  years: 1993-1994, 1996-1998, 2000, 2003-2009, 2012-2013
+debian:
+  summary: |
+    A Debian package is included in Debian 5.0 (lenny) and later releases.
+    Thanks to Guido Guenther for doing the initial upload to Debian.
+description: |
+  lbcd provides a lightweight way to query a system via unauthenticated UDP
+  for system load information plus some related information that may be
+  relevant to determining which system to hand out.  It was designed for use
+  with the [lbnamed DNS load
+  balancer](https://www.stanford.edu/~riepel/lbnamed/).  System load, number
+  of logged-in users, free /tmp space, and system uptime are always
+  returned.  lbcd can also be configured to probe various local services and
+  modify the returned weights based on whether those services are reachable,
+  or to return a static weight for round-robin load balancing.
+
+  The information provided isn't particularly sophisticated, and a good
+  hardware load balancer will be able to consider such things as connection
+  latency and responsiveness to make better decisions.  However, lbcd with
+  lbnamed works quite well for smaller scale problems, scales well to
+  multiple load balance pools for different services, provides a simple UDP
+  health check service, and is much simpler and cheaper to understand and
+  deploy.
+
+  Included in this package is a small client program, lbcdclient, which can
+  query an lbcd server and display a formatted version of the returned
+  information.
+
+  It was originally written by Roland Schemers.  Larry Schwimmer rewrote it
+  to add protocol version 3 with some additional features and service
+  probing, and then I rewrote it again to update the coding style and use my
+  standard portability layer.
+distribution:
+  section: system
+  tarname: lbcd
+  version: lbcd
+docs:
+  user:
+  - name: lbcd
+    title: lbcd manual page
+  - name: lbcdclient
+    title: lbcdclient manual page
+format: v1
+license:
+  name: Expat
+maintainer: Russ Allbery <eagle@eyrie.org>
+name: lbcd
+orphaned: |
+  Although I believe it is still useful, I no longer use this method of DNS
+  load balancing and am no longer maintaining this package.  If you would
+  like to pick up maintenance of it, please feel free.  Contact me if you
+  would like this page to redirect to its new home.
+packaging:
+  debian: lbcd
+requirements: |
+  lbcd is written in C, so you'll need a C compiler.  It also uses kernel
+  calls to obtain load and uptime information, and at present has only been
+  ported to Linux, Solaris, AIX, various BSD systems, Mac OS X, HP-UX, IRIX,
+  and Tru64.  It is currently primarily tested on Linux.  Platforms not
+  listed may require some porting effort, as may old or unusual platforms
+  that aren't regularly tested.
+
+  The lbcdclient program requires Perl 5.6 or later and requires the
+  IO::Socket::INET6 module for IPv6 support.
+support:
+  email: eagle@eyrie.org
+  listname: lbnamed-users
+  listurl: https://mailman.stanford.edu/mailman/listinfo/lbnamed-users
+  web: https://www.eyrie.org/~eagle/software/lbcd/
+synopsis: responder for load balancing
+test:
+  suffix: |
+    Currently, the test suite only checks the portability and utility
+    libraries, not the functionality of lbcd or lbcdclient.
+vcs:
+  browse: https://git.eyrie.org/?p=system/lbcd.git
+  github: rra/lbcd
+  type: Git
+  url: https://git.eyrie.org/git/system/lbcd.git
+version: 3.4.2
diff --git a/t/data/update/lbcd/old/blurb b/t/data/update/lbcd/old/blurb
new file mode 100644
index 0000000..3689eb9
--- /dev/null
+++ b/t/data/update/lbcd/old/blurb
@@ -0,0 +1,6 @@
+lbcd is a daemon that runs on a UNIX system and answers UDP queries with
+information about system load, number of logged-on users, uptime, and free
+/tmp space.  This information can be used to accumulate system status
+across a cluster with light-weight queries or can be used as input to a
+load-balancing system to choose the best system to which to direct new
+incoming connections.
diff --git a/t/data/update/lbcd/old/build/middle b/t/data/update/lbcd/old/build/middle
new file mode 100644
index 0000000..6efe4de
--- /dev/null
+++ b/t/data/update/lbcd/old/build/middle
@@ -0,0 +1,9 @@
+lbcd looks for `$sysconfdir/nolbcd` and returns the maximum load if that
+file is present, allowing one to effectively drop a system out of a
+load-balanced pool by touching that file.  By default, the path is
+`/usr/local/etc/nolbcd`, but you may want to pass `--sysconfdir=/etc` to
+configure to use `/etc/nolbcd`.
+
+lbcdclient is written in Perl, so you may have to edit the first line of
+the script to point to the correct Perl location on your system.  It does
+not use any sophisticated Perl features or add-on modules.
diff --git a/t/data/update/lbcd/old/build/suffix b/t/data/update/lbcd/old/build/suffix
new file mode 100644
index 0000000..064769e
--- /dev/null
+++ b/t/data/update/lbcd/old/build/suffix
@@ -0,0 +1,6 @@
+You will generally want to start lbcd at system boot.  All that is needed
+is a simple init script to start lbcd with the appropriate options or kill
+it again.  It writes its PID into `/var/run/lbcd.pid` by default (and this
+can be changed with the `-P` option).  On many systems, lbcd will need to
+run as root or as a member of particular groups to obtain system load
+average and uptime information.
diff --git a/t/data/update/lbcd/old/debian/summary b/t/data/update/lbcd/old/debian/summary
new file mode 100644
index 0000000..18524cb
--- /dev/null
+++ b/t/data/update/lbcd/old/debian/summary
@@ -0,0 +1,2 @@
+A Debian package is included in Debian 5.0 (lenny) and later releases.
+Thanks to Guido Guenther for doing the initial upload to Debian.
diff --git a/t/data/update/lbcd/old/description b/t/data/update/lbcd/old/description
new file mode 100644
index 0000000..c367a1b
--- /dev/null
+++ b/t/data/update/lbcd/old/description
@@ -0,0 +1,26 @@
+lbcd provides a lightweight way to query a system via unauthenticated UDP
+for system load information plus some related information that may be
+relevant to determining which system to hand out.  It was designed for use
+with the [lbnamed DNS load
+balancer](https://www.stanford.edu/~riepel/lbnamed/).  System load, number
+of logged-in users, free /tmp space, and system uptime are always
+returned.  lbcd can also be configured to probe various local services and
+modify the returned weights based on whether those services are reachable,
+or to return a static weight for round-robin load balancing.
+
+The information provided isn't particularly sophisticated, and a good
+hardware load balancer will be able to consider such things as connection
+latency and responsiveness to make better decisions.  However, lbcd with
+lbnamed works quite well for smaller scale problems, scales well to
+multiple load balance pools for different services, provides a simple UDP
+health check service, and is much simpler and cheaper to understand and
+deploy.
+
+Included in this package is a small client program, lbcdclient, which can
+query an lbcd server and display a formatted version of the returned
+information.
+
+It was originally written by Roland Schemers.  Larry Schwimmer rewrote it
+to add protocol version 3 with some additional features and service
+probing, and then I rewrote it again to update the coding style and use my
+standard portability layer.
diff --git a/t/data/update/lbcd/old/metadata.json b/t/data/update/lbcd/old/metadata.json
new file mode 100644
index 0000000..36efc1c
--- /dev/null
+++ b/t/data/update/lbcd/old/metadata.json
@@ -0,0 +1,53 @@
+{
+    "name": "lbcd",
+    "version": "3.4.2",
+    "synopsis": "responder for load balancing",
+    "maintainer": "Russ Allbery <eagle@eyrie.org>",
+    "orphaned": true,
+    "copyrights": [
+        {
+            "holder": "The Board of Trustees of the Leland Stanford Junior University",
+            "years": "1993-1994, 1996-1998, 2000, 2003-2009, 2012-2013",
+        },
+    ],
+    "license": "Expat",
+    "build": {
+        "lancaster": true,
+        "autotools": true,
+        "automake": "1.11",
+        "autoconf": "2.64",
+        "type": "Autoconf"
+    },
+    "packaging": {
+        "debian": "lbcd",
+    },
+    "support": {
+        "email": "eagle@eyrie.org",
+        "listname": "lbnamed-users",
+        "listurl": "https://mailman.stanford.edu/mailman/listinfo/lbnamed-users",
+        "web": "https://www.eyrie.org/~eagle/software/lbcd/",
+    },
+    "vcs": {
+        "type": "Git",
+        "url": "https://git.eyrie.org/git/system/lbcd.git",
+        "browse": "https://git.eyrie.org/?p=system/lbcd.git",
+        "github": "rra/lbcd",
+    },
+    "distribution": {
+        "section": "system",
+        "tarname": "lbcd",
+        "version": "lbcd",
+    },
+    "docs": {
+        "user": [
+            {
+                "name": "lbcd",
+                "title": "lbcd manual page",
+            },
+            {
+                "name": "lbcdclient",
+                "title": "lbcdclient manual page",
+            },
+        ],
+    },
+}
diff --git a/t/data/update/lbcd/old/orphaned b/t/data/update/lbcd/old/orphaned
new file mode 100644
index 0000000..7f62227
--- /dev/null
+++ b/t/data/update/lbcd/old/orphaned
@@ -0,0 +1,4 @@
+Although I believe it is still useful, I no longer use this method of DNS
+load balancing and am no longer maintaining this package.  If you would
+like to pick up maintenance of it, please feel free.  Contact me if you
+would like this page to redirect to its new home.
diff --git a/t/data/update/lbcd/old/requirements b/t/data/update/lbcd/old/requirements
new file mode 100644
index 0000000..8c3eace
--- /dev/null
+++ b/t/data/update/lbcd/old/requirements
@@ -0,0 +1,9 @@
+lbcd is written in C, so you'll need a C compiler.  It also uses kernel
+calls to obtain load and uptime information, and at present has only been
+ported to Linux, Solaris, AIX, various BSD systems, Mac OS X, HP-UX, IRIX,
+and Tru64.  It is currently primarily tested on Linux.  Platforms not
+listed may require some porting effort, as may old or unusual platforms
+that aren't regularly tested.
+
+The lbcdclient program requires Perl 5.6 or later and requires the
+IO::Socket::INET6 module for IPv6 support.
diff --git a/t/data/update/lbcd/old/test/suffix b/t/data/update/lbcd/old/test/suffix
new file mode 100644
index 0000000..3626ede
--- /dev/null
+++ b/t/data/update/lbcd/old/test/suffix
@@ -0,0 +1,2 @@
+Currently, the test suite only checks the portability and utility
+libraries, not the functionality of lbcd or lbcdclient.
diff --git a/t/data/update/pam-krb5/docknot.yaml b/t/data/update/pam-krb5/docknot.yaml
new file mode 100644
index 0000000..1a329a5
--- /dev/null
+++ b/t/data/update/pam-krb5/docknot.yaml
@@ -0,0 +1,509 @@
+---
+advisories:
+- date: 2009-02-11
+  threshold: '3.13'
+  versions: 3.12 and earlier
+blurb: |
+  pam-krb5 is a Kerberos PAM module for either MIT Kerberos or Heimdal.  It
+  supports ticket refreshing by screen savers, configurable authorization
+  handling, authentication of non-local accounts for network services,
+  password changing, and password expiration, as well as all the standard
+  expected PAM features.  It works correctly with OpenSSH, even with
+  ChallengeResponseAuthentication and PrivilegeSeparation enabled, and
+  supports extensive configuration either by PAM options or in krb5.conf or
+  both.  PKINIT is supported with recent versions of both MIT Kerberos and
+  Heimdal and FAST is supported with recent MIT Kerberos.
+build:
+  autoconf: '2.64'
+  automake: '1.11'
+  autotools: true
+  kerberos: true
+  manpages: true
+  middle: |
+    The module will be installed in `/usr/local/lib/security` by default,
+    except on 64-bit versions of Linux which will use
+    `/usr/local/lib64/security` to match the default PAM configuration.  You
+    can change the installation locations with the `--prefix`, `--mandir`, and
+    `--libdir` options to configure.  The module will always be installed in a
+    subdirectory named `security` under the specified libdir.  On Linux, use
+    `--prefix=/usr` to install the man page into `/usr/share/man` and the PAM
+    module in `/lib/security` or `/lib64/security`.
+  reduced_depends: true
+  type: Autoconf
+copyrights:
+- holder: Russ Allbery <eagle@eyrie.org>
+  years: 2005-2010, 2014-2015, 2017
+- holder: The Board of Trustees of the Leland Stanford Junior University
+  years: 2009-2011
+- holder: Andres Salomon <dilinger@debian.org>
+  years: '2005'
+- holder: Frank Cusack <fcusack@fcusack.com>
+  years: 1999-2000
+debian:
+  summary: |
+    Debian packages are available from Debian in Debian 4.0 (etch) and later
+    releases as libpam-krb5 and libpam-heimdal.  The former packages are built
+    against the MIT Kerberos libraries and the latter against the Heimdal
+    libraries.
+description: |
+  pam-krb5 provides a Kerberos PAM module that supports authentication, user
+  ticket cache handling, simple authorization (via .k5login or checking
+  Kerberos principals against local usernames), and password changing.  It
+  can be configured through either options in the PAM configuration itself
+  or through entries in the system krb5.conf file, and it tries to work
+  around PAM implementation flaws in commonly-used PAM-enabled applications
+  such as OpenSSH and xdm.  It supports both PKINIT and FAST to the extent
+  that the underlying Kerberos libraries support these features.
+
+  This is not the Kerberos PAM module maintained on Sourceforge and used on
+  Red Hat systems.  It is an independent implementation that, if it ever
+  shared any common code, diverged long ago.  It supports some features that
+  the Sourceforge module does not (particularly around authorization), and
+  does not support some options (particularly ones not directly related to
+  Kerberos) that it does.  This module will never support Kerberos v4 or
+  AFS.  For an AFS session module that works with this module (or any other
+  Kerberos PAM module), see
+  [pam-afs-session](https://www.eyrie.org/~eagle/software/pam-afs-session/).
+
+  If there are other options besides AFS and Kerberos v4 support from the
+  Sourceforge PAM module that you're missing in this module, please let me
+  know.
+distribution:
+  section: kerberos
+  tarname: pam-krb5
+  version: pam-krb5
+docs:
+  user:
+  - name: pam-krb5
+    title: Manual page
+format: v1
+license:
+  name: BSD-3-clause-or-GPL-1+
+maintainer: Russ Allbery <eagle@eyrie.org>
+name: pam-krb5
+packaging:
+  debian: libpam-krb5
+quote:
+  author: Joyce McGreevy
+  date: 2003-11-17
+  text: |
+    "You're always going to have some people who can't appreciate the thrill
+    of a tepid change for the somewhat better," explained one source.
+  title: '"Look, ma, no hands!"'
+  work: Salon
+readme:
+  sections:
+  - body: |
+      Just installing the module does not enable it or change anything about
+      your system authentication configuration.  To use the module for all
+      system authentication on Debian systems, put something like:
+
+      ```
+          auth  sufficient   pam_krb5.so minimum_uid=1000
+          auth  required     pam_unix.so try_first_pass nullok_secure
+      ```
+
+      in `/etc/pam.d/common-auth`, something like:
+
+      ```
+          session  optional  pam_krb5.so minimum_uid=1000
+          session  required  pam_unix.so
+      ```
+
+      in `/etc/pam.d/common-session`, and something like:
+
+      ```
+          account  required  pam_krb5.so minimum_uid=1000
+          account  required  pam_unix.so
+      ```
+
+      in `/etc/pam.d/common-account`.  The `minimum_uid` setting tells the PAM
+      module to pass on any users with a UID lower than 1000, thereby bypassing
+      Kerberos authentication for the root account and any system accounts.  You
+      normally want to do this since otherwise, if the network is down, the
+      Kerberos authentication can time out and make it difficult to log in as
+      root and fix matters.  This also avoids problems with Kerberos principals
+      that happen to match system accounts accidentally getting access to those
+      accounts.
+
+      Be sure to include the module in the session group as well as the auth
+      group.  Without the session entry, the user's ticket cache will not be
+      created properly for ssh logins (among possibly others).
+
+      If your users should normally all use Kerberos passwords exclusively,
+      putting something like:
+
+      ```
+          password sufficient pam_krb5.so minimum_uid=1000
+          password required   pam_unix.so try_first_pass obscure md5
+      ```
+
+      in `/etc/pam.d/common-password` will change users' passwords in Kerberos
+      by default and then only fall back on Unix if that doesn't work.  (You can
+      make this tighter by using the more complex new-style PAM configuration.)
+      If you instead want to synchronize local and Kerberos passwords and change
+      them both at the same time, you can do something like:
+
+      ```
+          password required   pam_unix.so obscure sha512
+          password required   pam_krb5.so use_authtok minimum_uid=1000
+      ```
+
+      If you have multiple environments that you want to synchronize and you
+      don't want password changes to continue if the Kerberos password change
+      fails, use the `clear_on_fail` option.  For example:
+
+      ```
+          password required   pam_krb5.so clear_on_fail minimum_uid=1000
+          password required   pam_unix.so use_authtok obscure sha512
+          password required   pam_smbpass.so use_authtok
+      ```
+
+      In this case, if `pam_krb5` cannot change the password (due to password
+      strength rules on the KDC, for example), it will clear the stored password
+      (because of the `clear_on_fail` option), and since `pam_unix` and
+      `pam_smbpass` are both configured with `use_authtok`, they will both fail.
+      `clear_on_fail` is not the default because it would interfere with the
+      more common pattern of falling back to local passwords if the user doesn't
+      exist in Kerberos.
+
+      If you use a more complex configuration with the Linux PAM `[]` syntax for
+      the session and account groups, note that `pam_krb5` returns a status of
+      ignore, not success, if the user didn't log on with Kerberos.  You may
+      need to handle that explicitly with `ignore=ignore` in your action list.
+
+      There are many, many other possibilities.  See the Linux PAM documentation
+      for all the configuration options.
+
+      On Red Hat systems, modify `/etc/pam.d/system-auth` instead, which
+      contains all of the configuration for the different stacks.
+
+      You can also use pam-krb5 only for specific services.  In that case,
+      modify the files in `/etc/pam.d` for that particular service to use
+      `pam_krb5.so` for authentication.  For services that are using passwords
+      over TLS to authenticate users, you may want to use the `ignore_k5login`
+      and `no_ccache` options to the authenticate module.  `.k5login`
+      authorization is only meaningful for local accounts and ticket caches are
+      usually (although not always) only useful for interactive sessions.
+
+      Configuring the module for Solaris is both simpler and less flexible,
+      since Solaris (at least Solaris 8 and 9, which are the last versions of
+      Solaris with which this module was extensively tested) use a single
+      `/etc/pam.conf` file that contains configuration for all programs.  For
+      console login on Solaris, try something like:
+
+      ```
+          login auth sufficient /usr/local/lib/security/pam_krb5.so minimum_uid=100
+          login auth required /usr/lib/security/pam_unix_auth.so.1 use_first_pass
+          login account required /usr/local/lib/security/pam_krb5.so minimum_uid=100
+          login account required /usr/lib/security/pam_unix_account.so.1
+          login session required /usr/local/lib/security/pam_krb5.so retain_after_close minimum_uid=100
+          login session required /usr/lib/security/pam_unix_session.so.1
+      ```
+
+      A similar configuration could be used for other services, such as ssh.
+      See the pam.conf(5) man page for more information.  When using this module
+      with Solaris login (at least on Solaris 8 and 9), you will probably also
+      need to add `retain_after_close` to the PAM configuration to avoid having
+      the user's credentials deleted before they are logged in.
+
+      The Solaris Kerberos library reportedly does not support prompting for a
+      password change of an expired account during authentication.  Supporting
+      password change for expired accounts on Solaris with native Kerberos may
+      therefore require setting the `defer_pwchange` or `force_pwchange` option
+      for selected login applications.  See the description and warnings about
+      that option in the pam_krb5(5) man page.
+
+      Some configuration options may be put in the `krb5.conf` file used by your
+      Kerberos libraries (usually `/etc/krb5.conf` or
+      `/usr/local/etc/krb5.conf`) instead or in addition to the PAM
+      configuration.  See the man page for more details.
+
+      The Kerberos library, via pam-krb5, will prompt the user to change their
+      password if their password is expired, but when using OpenSSH, this will
+      only work when `ChallengeResponseAuthentication` is enabled.  Unless this
+      option is enabled, OpenSSH doesn't pass PAM messages to the user and can
+      only respond to a simple password prompt.
+
+      If you are using MIT Kerberos, be aware that users whose passwords are
+      expired will not be prompted to change their password unless the KDC
+      configuration for your realm in `[realms]` in `krb5.conf` contains a
+      `master_kdc` setting or, if using DNS SRV records, you have a DNS entry
+      for `_kerberos-master` as well as `_kerberos`.
+    title: Configuring
+  - body: |
+      The first step when debugging any problems with this module is to add
+      `debug` to the PAM options for the module (either in the PAM configuration
+      or in `krb5.conf`).  This will significantly increase the logging from the
+      module and should provide a trace of exactly what failed and any available
+      error information.
+
+      Many Kerberos authentication problems are due to configuration issues in
+      `krb5.conf`.  If pam-krb5 doesn't work, first check that `kinit` works on
+      the same system.  That will test your basic Kerberos configuration.  If
+      the system has a keytab file installed that's readable by the process
+      doing authentication via PAM, make sure that the keytab is current and
+      contains a key for `host/<system>` where <system> is the fully-qualified
+      hostname.  pam-krb5 prevents KDC spoofing by checking the user's
+      credentials when possible, but this means that if a keytab is present it
+      must be correct or authentication will fail.  You can check the keytab
+      with `klist -k` and `kinit -k`.
+
+      Be sure that all libraries and modules, including PAM modules, loaded by a
+      program use the same Kerberos libraries.  Sometimes programs that use PAM,
+      such as current versions of OpenSSH, also link against Kerberos directly.
+      If your sshd is linked against one set of Kerberos libraries and pam-krb5
+      is linked against a different set of Kerberos libraries, this will often
+      cause problems (such as segmentation faults, bus errors, assertions, or
+      other strange behavior).  Similar issues apply to the com_err library or
+      any other library used by both modules and shared libraries and by the
+      application that loads them.  If your OS ships Kerberos libraries, it's
+      usually best if possible to build all Kerberos software on the system
+      against those libraries.
+    title: Debugging
+  - body: |
+      The normal sequence of actions taken for a user login is:
+
+      ```
+          pam_authenticate
+          pam_setcred(PAM_ESTABLISH_CRED)
+          pam_open_session
+          pam_acct_mgmt
+      ```
+
+      and then at logout:
+
+      ```
+          pam_close_session
+      ```
+
+      followed by closing the open PAM session.  The corresponding `pam_sm_*`
+      functions in this module are called when an application calls those public
+      interface functions.  Not all applications call all of those functions, or
+      in particularly that order, although `pam_authenticate` is always first
+      and has to be.
+
+      When `pam_authenticate` is called, pam-krb5 creates a temporary ticket
+      cache in `/tmp` and sets the PAM environment variable `PAM_KRB5CCNAME` to
+      point to it.  This ticket cache will be automatically destroyed when the
+      PAM session is closed and is there only to pass the initial credentials to
+      the call to `pam_setcred`.  The module would use a memory cache, but
+      memory caches will only work if the application preserves the PAM
+      environment between the calls to `pam_authenticate` and `pam_setcred`.
+      Most do, but OpenSSH notoriously does not and calls `pam_authenticate` in
+      a subprocess, so this method is used to pass the tickets to the
+      `pam_setcred` call in a different process.
+
+      `pam_authenticate` does a complete authentication, including checking the
+      resulting TGT by obtaining a service ticket for the local host if
+      possible, but this requires read access to the system keytab.  If the
+      keytab doesn't exist, can't be read, or doesn't include the appropriate
+      credentials, the default is to accept the authentication.  This can be
+      controlled by setting `verify_ap_req_nofail` to true in `[libdefaults]` in
+      `/etc/krb5.conf`.  `pam_authenticate` also does a basic authorization
+      check, by default calling `krb5_kuserok` (which uses `~/.k5login` if
+      available and falls back to checking that the principal corresponds to the
+      account name).  This can be customized with several options documented in
+      the pam_krb5(5) man page.
+
+      pam-krb5 treats `pam_open_session` and `pam_setcred(PAM_ESTABLISH_CRED)`
+      as synonymous, as some applications call one and some call the other.
+      Both copy the initial credentials from the temporary cache into a
+      permanent cache for this session and set `KRB5CCNAME` in the environment.
+      It will remember when the credential cache has been established and then
+      avoid doing any duplicate work afterwards, since some applications call
+      `pam_setcred` or `pam_open_session` multiple times (most notably X.Org 7
+      and earlier xdm, which also throws away the module settings the last time
+      it calls them).
+
+      `pam_acct_mgmt` finds the ticket cache, reads it in to obtain the
+      authenticated principal, and then does is another authorization check
+      against `.k5login` or the local account name as described above.
+
+      After the call to `pam_setcred` or `pam_open_session`, the ticket cache
+      will be destroyed whenever the calling application either destroys the PAM
+      environment or calls `pam_close_session`, which it should do on user
+      logout.
+
+      The normal sequence of events when refreshing a ticket cache (such as
+      inside a screensaver) is:
+
+      ```
+          pam_authenticate
+          pam_setcred(PAM_REINITIALIZE_CRED)
+          pam_acct_mgmt
+      ```
+
+      (`PAM_REFRESH_CRED` may be used instead.)  Authentication proceeds as
+      above.  At the `pam_setcred` stage, rather than creating a new ticket
+      cache, the module instead finds the current ticket cache (from the
+      `KRB5CCNAME` environment variable or the default ticket cache location
+      from the Kerberos library) and then reinitializes it with the credentials
+      from the temporary `pam_authenticate` ticket cache.  When refreshing a
+      ticket cache, the application should not open a session.  Calling
+      `pam_acct_mgmt` is optional; pam-krb5 doesn't do anything different when
+      it's called in this case.
+
+      If `pam_authenticate` apparently didn't succeed, or if an account was
+      configured to be ignored via `ignore_root` or `minimum_uid`, `pam_setcred`
+      (and therefore `pam_open_session`) and `pam_acct_mgmt` return
+      `PAM_IGNORE`, which tells the PAM library to proceed as if that module
+      wasn't listed in the PAM configuration at all.  `pam_authenticate`,
+      however, returns failure in the ignored user case by default, since
+      otherwise a configuration using `ignore_root` with pam-krb5 as the only
+      PAM module would allow anyone to log in as root without a password.  There
+      doesn't appear to be a case where returning `PAM_IGNORE` instead would
+      improve the module's behavior, but if you know of a case, please let me
+      know.
+
+      By default, `pam_authenticate` intentionally does not follow the PAM
+      standard for handling expired accounts and instead returns failure from
+      `pam_authenticate` unless the Kerberos libraries are able to change the
+      account password during authentication.  Too many applications either do
+      not call `pam_acct_mgmt` or ignore its exit status.  The fully correct PAM
+      behavior (returning success from `pam_authenticate` and
+      `PAM_NEW_AUTHTOK_REQD` from `pam_acct_mgmt`) can be enabled with the
+      `defer_pwchange` option.
+
+      The `defer_pwchange` option is unfortunately somewhat tricky to implement.
+      In this case, the calling sequence is:
+
+      ```
+          pam_authenticate
+          pam_acct_mgmt
+          pam_chauthtok
+          pam_setcred
+          pam_open_session
+      ```
+
+      During the first `pam_authenticate`, we can't obtain credentials and
+      therefore a ticket cache since the password is expired.  But
+      `pam_authenticate` isn't called again after `pam_chauthtok`, so
+      `pam_chauthtok` has to create a ticket cache.  We however don't want it to
+      do this for the normal password change (`passwd`) case.
+
+      What we do is set a flag in our PAM data structure saying that we're
+      processing an expired password, and `pam_chauthtok`, if it sees that flag,
+      redoes the authentication with password prompting disabled after it
+      finishes changing the password.
+
+      Unfortunately, when handling password changes this way, `pam_chauthtok`
+      will always have to prompt the user for their current password again even
+      though they just typed it.  This is because the saved authentication
+      tokens are cleared after `pam_authenticate` returns, for security reasons.
+      We could hack around this by saving the password in our PAM data
+      structure, but this would let the application gain access to it (exactly
+      what the clearing is intended to prevent) and breaks a PAM library
+      guarantee.  We could also work around this by having `pam_authenticate`
+      get the `kadmin/changepw` authenticator in the expired password case and
+      store it for `pam_chauthtok`, but it doesn't seem worth the hassle.
+    title: Implementation Notes
+  - body: |
+      Originally written by Frank Cusack <fcusack@fcusack.com>, with the
+      following acknowledgement:
+
+      > Thanks to Naomaru Itoi <itoi@eecs.umich.edu>, Curtis King
+      > <curtis.king@cul.ca>, and Derrick Brashear <shadow@dementia.org>, all of
+      > whom have written and made available Kerberos 4/5 modules.  Although no
+      > code in this module is directly from these author's modules, (except the
+      > get_user_info() routine in support.c; derived from whichever of these
+      > authors originally wrote the first module the other 2 copied from), it
+      > was extremely helpful to look over their code which aided in my design.
+
+      The module was then patched for the FreeBSD ports collection with
+      additional modifications by unknown maintainers and then was modified by
+      Joel Kociolek <joko@logidee.com> to be usable with Debian GNU/Linux.
+
+      It was packaged by Sam Hartman as the Kerberos v5 PAM module for Debian
+      and improved and modified by him and later by Russ Allbery to fix bugs and
+      add additional features.  It was then adopted by Andres Salomon, who added
+      support for refreshing credentials.
+
+      The current distribution is maintained by Russ Allbery, who also added
+      support for reading configuration from `krb5.conf`, added many features
+      for compatibility with the Sourceforge module, commented and standardized
+      the formatting of the code, and overhauled the documentation.
+
+      Thanks to Douglas E. Engert for the initial implementation of PKINIT
+      support.  I have since modified and reworked it extensively, so any bugs
+      or compilation problems are my fault.
+
+      Thanks to Markus Moeller for lots of debugging and multiple patches and
+      suggestions for improved portability.
+
+      Thanks to Booker Bense for the implementation of the `alt_auth_map`
+      option.
+
+      Thanks to Sam Hartman for the FAST support implementation.
+    title: History and Acknowledgements
+requirements: |
+  Either MIT Kerberos (or Kerberos implementations based on it) or Heimdal
+  are supported.  MIT Keberos 1.3 or later may be required; this module has
+  not been tested with earlier versions.
+
+  For PKINIT support, Heimdal 0.8rc1 or later or MIT Kerberos 1.6.3 or later
+  are required.  Earlier MIT Kerberos 1.6 releases have a bug in their
+  handling of PKINIT options.
+
+  For FAST (Flexible Authentication Secure Tunneling) support, MIT Kerberos
+  1.7 or higher is required.  For anonymous FAST support, anonymous
+  authentication (generally anonymous PKINIT) support is required in both
+  the Kerberos libraries and in the local KDC.
+
+  This module should work on Linux and Solaris (and build with gcc, clang,
+  or the Sun C compiler), but has been far more heavily tested on Linux.
+  There is beta-quality support for the AIX NAS Kerberos implementation.
+  Other PAM implementations will probably require some porting, although
+  untested build system support is present for FreeBSD, Mac OS X, and HP-UX.
+  I personally can only test on Linux and rely on others to report problems
+  on other operating systems.
+
+  Old versions of OpenSSH are known to call `pam_authenticate` followed by
+  `pam_setcred(PAM_REINITIALIZE_CRED)` without first calling
+  `pam_open_session`, thereby requesting that an existing ticket cache be
+  renewed (similar to what a screensaver would want) rather than requesting
+  a new ticket cache be created.  Since this behavior is indistinguishable
+  at the PAM level from a screensaver, pam-krb5 when used with these old
+  versions of OpenSSH will refresh the ticket cache of the OpenSSH daemon
+  rather than setting up a new ticket cache for the user.  The resulting
+  ticket cache will have the correct permissions (this is not a security
+  concern), but will not be named correctly or referenced in the user's
+  environment and will be overwritten by the next user login.  The best
+  solution to this problem is to upgrade OpenSSH.  I'm not sure exactly when
+  this problem was fixed, but at the very least OpenSSH 4.3 and later do not
+  exhibit it.
+support:
+  email: eagle@eyrie.org
+  github: rra/pam-krb5
+  web: https://www.eyrie.org/~eagle/software/pam-krb5/
+synopsis: PAM module for Kerberos authentication
+test:
+  prefix: |
+    pam-krb5 comes with a comprehensive test suite, but it requires some
+    configuration in order to test anything other than low-level utility
+    functions.  For the full test suite, you will need to have a running KDC
+    in which you can create two test accounts, one with admin access to the
+    other.  Using a test KDC environment, if you have one, is recommended.
+
+    Follow the instructions in `tests/config/README` to configure the test
+    suite.
+
+    Now, you can run the test suite with:
+  suffix: |
+    The default libkadm5clnt library on the system must match the
+    implementation of your KDC for the module/expired test to work, since the
+    two kadmin protocols are not compatible.  If you use the MIT library
+    against a Heimdal server, the test will be skipped; if you use the Heimdal
+    library against an MIT server, the test suite may hang.
+
+    Several `module/expired` tests are expected to fail with Heimdal 1.5 due
+    to a bug in Heimdal with reauthenticating immediately after a
+    library-mediated password change of an expired password.  This is fixed in
+    later releases of Heimdal.
+vcs:
+  browse: https://git.eyrie.org/?p=kerberos/pam-krb5.git
+  github: rra/pam-krb5
+  openhub: https://www.openhub.net/p/pamkrb5
+  type: Git
+  url: https://git.eyrie.org/git/kerberos/pam-krb5.git
+version: '4.8'
diff --git a/t/data/update/pam-krb5/old/README b/t/data/update/pam-krb5/old/README
new file mode 100644
index 0000000..26316da
--- /dev/null
+++ b/t/data/update/pam-krb5/old/README
@@ -0,0 +1,6 @@
+This directory contains configuration for DocKnot used to generate
+documentation files (like README.md) and web pages.  Other documentation
+in this package is generated automatically from these files as part of the
+release process.  For more information, see DocKnot's documentation.
+
+DocKnot is available from <https://www.eyrie.org/~eagle/software/docknot/>.
diff --git a/t/data/update/pam-krb5/old/blurb b/t/data/update/pam-krb5/old/blurb
new file mode 100644
index 0000000..a78f46f
--- /dev/null
+++ b/t/data/update/pam-krb5/old/blurb
@@ -0,0 +1,9 @@
+pam-krb5 is a Kerberos PAM module for either MIT Kerberos or Heimdal.  It
+supports ticket refreshing by screen savers, configurable authorization
+handling, authentication of non-local accounts for network services,
+password changing, and password expiration, as well as all the standard
+expected PAM features.  It works correctly with OpenSSH, even with
+ChallengeResponseAuthentication and PrivilegeSeparation enabled, and
+supports extensive configuration either by PAM options or in krb5.conf or
+both.  PKINIT is supported with recent versions of both MIT Kerberos and
+Heimdal and FAST is supported with recent MIT Kerberos.
diff --git a/t/data/update/pam-krb5/old/build/middle b/t/data/update/pam-krb5/old/build/middle
new file mode 100644
index 0000000..a168962
--- /dev/null
+++ b/t/data/update/pam-krb5/old/build/middle
@@ -0,0 +1,8 @@
+The module will be installed in `/usr/local/lib/security` by default,
+except on 64-bit versions of Linux which will use
+`/usr/local/lib64/security` to match the default PAM configuration.  You
+can change the installation locations with the `--prefix`, `--mandir`, and
+`--libdir` options to configure.  The module will always be installed in a
+subdirectory named `security` under the specified libdir.  On Linux, use
+`--prefix=/usr` to install the man page into `/usr/share/man` and the PAM
+module in `/lib/security` or `/lib64/security`.
diff --git a/t/data/update/pam-krb5/old/debian/summary b/t/data/update/pam-krb5/old/debian/summary
new file mode 100644
index 0000000..f6dc7f4
--- /dev/null
+++ b/t/data/update/pam-krb5/old/debian/summary
@@ -0,0 +1,4 @@
+Debian packages are available from Debian in Debian 4.0 (etch) and later
+releases as libpam-krb5 and libpam-heimdal.  The former packages are built
+against the MIT Kerberos libraries and the latter against the Heimdal
+libraries.
diff --git a/t/data/update/pam-krb5/old/description b/t/data/update/pam-krb5/old/description
new file mode 100644
index 0000000..2220c95
--- /dev/null
+++ b/t/data/update/pam-krb5/old/description
@@ -0,0 +1,22 @@
+pam-krb5 provides a Kerberos PAM module that supports authentication, user
+ticket cache handling, simple authorization (via .k5login or checking
+Kerberos principals against local usernames), and password changing.  It
+can be configured through either options in the PAM configuration itself
+or through entries in the system krb5.conf file, and it tries to work
+around PAM implementation flaws in commonly-used PAM-enabled applications
+such as OpenSSH and xdm.  It supports both PKINIT and FAST to the extent
+that the underlying Kerberos libraries support these features.
+
+This is not the Kerberos PAM module maintained on Sourceforge and used on
+Red Hat systems.  It is an independent implementation that, if it ever
+shared any common code, diverged long ago.  It supports some features that
+the Sourceforge module does not (particularly around authorization), and
+does not support some options (particularly ones not directly related to
+Kerberos) that it does.  This module will never support Kerberos v4 or
+AFS.  For an AFS session module that works with this module (or any other
+Kerberos PAM module), see
+[pam-afs-session](https://www.eyrie.org/~eagle/software/pam-afs-session/).
+
+If there are other options besides AFS and Kerberos v4 support from the
+Sourceforge PAM module that you're missing in this module, please let me
+know.
diff --git a/t/data/update/pam-krb5/old/metadata.json b/t/data/update/pam-krb5/old/metadata.json
new file mode 100644
index 0000000..7d424a3
--- /dev/null
+++ b/t/data/update/pam-krb5/old/metadata.json
@@ -0,0 +1,83 @@
+{
+    "name": "pam-krb5",
+    "version": "4.8",
+    "synopsis": "PAM module for Kerberos authentication",
+    "maintainer": "Russ Allbery <eagle@eyrie.org>",
+    "copyrights": [
+        {
+            "holder": "Russ Allbery <eagle@eyrie.org>",
+            "years": "2005-2010, 2014-2015, 2017",
+        },
+        {
+            "holder": "The Board of Trustees of the Leland Stanford Junior University",
+            "years": "2009-2011",
+        },
+        {
+            "holder": "Andres Salomon <dilinger@debian.org>",
+            "years": "2005",
+        },
+        {
+            "holder": "Frank Cusack <fcusack@fcusack.com>",
+            "years": "1999-2000",
+        },
+    ],
+    "license": "BSD-3-clause-or-GPL-1+",
+    "build": {
+        "autoconf": "2.64",
+        "automake": "1.11",
+        "autotools": true,
+        "kerberos": true,
+        "manpages": true,
+        "reduced_depends": true,
+        "type": "Autoconf",
+    },
+    "support": {
+        "email": "eagle@eyrie.org",
+        "github": "rra/pam-krb5",
+        "web": "https://www.eyrie.org/~eagle/software/pam-krb5/",
+    },
+    "vcs": {
+        "type": "Git",
+        "url": "https://git.eyrie.org/git/kerberos/pam-krb5.git",
+        "browse": "https://git.eyrie.org/?p=kerberos/pam-krb5.git",
+        "github": "rra/pam-krb5",
+        "openhub": "https://www.openhub.net/p/pamkrb5",
+    },
+    "readme": {
+        "sections": [
+            { "title": "Configuring" },
+            { "title": "Debugging" },
+            { "title": "Implementation Notes" },
+            { "title": "History and Acknowledgements" },
+        ],
+    },
+    "quote": {
+        "author": "Joyce McGreevy",
+        "title": "\"Look, ma, no hands!\"",
+        "work": "Salon",
+        "date": "2003-11-17",
+    },
+    "distribution": {
+        "section": "kerberos",
+        "tarname": "pam-krb5",
+        "version": "pam-krb5",
+    },
+    "packaging": {
+        "debian": "libpam-krb5",
+    },
+    "advisories": [
+        {
+            "date": "2009-02-11",
+            "versions": "3.12 and earlier",
+            "threshold": "3.13",
+        },
+    ],
+    "docs": {
+        "user": [
+            {
+                "name": "pam-krb5",
+                "title": "Manual page",
+            },
+        ],
+    },
+}
diff --git a/t/data/update/pam-krb5/old/quote b/t/data/update/pam-krb5/old/quote
new file mode 100644
index 0000000..6b59a00
--- /dev/null
+++ b/t/data/update/pam-krb5/old/quote
@@ -0,0 +1,2 @@
+"You're always going to have some people who can't appreciate the thrill
+of a tepid change for the somewhat better," explained one source.
diff --git a/t/data/update/pam-krb5/old/requirements b/t/data/update/pam-krb5/old/requirements
new file mode 100644
index 0000000..b871e0e
--- /dev/null
+++ b/t/data/update/pam-krb5/old/requirements
@@ -0,0 +1,35 @@
+Either MIT Kerberos (or Kerberos implementations based on it) or Heimdal
+are supported.  MIT Keberos 1.3 or later may be required; this module has
+not been tested with earlier versions.
+
+For PKINIT support, Heimdal 0.8rc1 or later or MIT Kerberos 1.6.3 or later
+are required.  Earlier MIT Kerberos 1.6 releases have a bug in their
+handling of PKINIT options.
+
+For FAST (Flexible Authentication Secure Tunneling) support, MIT Kerberos
+1.7 or higher is required.  For anonymous FAST support, anonymous
+authentication (generally anonymous PKINIT) support is required in both
+the Kerberos libraries and in the local KDC.
+
+This module should work on Linux and Solaris (and build with gcc, clang,
+or the Sun C compiler), but has been far more heavily tested on Linux.
+There is beta-quality support for the AIX NAS Kerberos implementation.
+Other PAM implementations will probably require some porting, although
+untested build system support is present for FreeBSD, Mac OS X, and HP-UX.
+I personally can only test on Linux and rely on others to report problems
+on other operating systems.
+
+Old versions of OpenSSH are known to call `pam_authenticate` followed by
+`pam_setcred(PAM_REINITIALIZE_CRED)` without first calling
+`pam_open_session`, thereby requesting that an existing ticket cache be
+renewed (similar to what a screensaver would want) rather than requesting
+a new ticket cache be created.  Since this behavior is indistinguishable
+at the PAM level from a screensaver, pam-krb5 when used with these old
+versions of OpenSSH will refresh the ticket cache of the OpenSSH daemon
+rather than setting up a new ticket cache for the user.  The resulting
+ticket cache will have the correct permissions (this is not a security
+concern), but will not be named correctly or referenced in the user's
+environment and will be overwritten by the next user login.  The best
+solution to this problem is to upgrade OpenSSH.  I'm not sure exactly when
+this problem was fixed, but at the very least OpenSSH 4.3 and later do not
+exhibit it.
diff --git a/t/data/update/pam-krb5/old/sections/configuring b/t/data/update/pam-krb5/old/sections/configuring
new file mode 100644
index 0000000..457d4c0
--- /dev/null
+++ b/t/data/update/pam-krb5/old/sections/configuring
@@ -0,0 +1,136 @@
+Just installing the module does not enable it or change anything about
+your system authentication configuration.  To use the module for all
+system authentication on Debian systems, put something like:
+
+```
+    auth  sufficient   pam_krb5.so minimum_uid=1000
+    auth  required     pam_unix.so try_first_pass nullok_secure
+```
+
+in `/etc/pam.d/common-auth`, something like:
+
+```
+    session  optional  pam_krb5.so minimum_uid=1000
+    session  required  pam_unix.so
+```
+
+in `/etc/pam.d/common-session`, and something like:
+
+```
+    account  required  pam_krb5.so minimum_uid=1000
+    account  required  pam_unix.so
+```
+
+in `/etc/pam.d/common-account`.  The `minimum_uid` setting tells the PAM
+module to pass on any users with a UID lower than 1000, thereby bypassing
+Kerberos authentication for the root account and any system accounts.  You
+normally want to do this since otherwise, if the network is down, the
+Kerberos authentication can time out and make it difficult to log in as
+root and fix matters.  This also avoids problems with Kerberos principals
+that happen to match system accounts accidentally getting access to those
+accounts.
+
+Be sure to include the module in the session group as well as the auth
+group.  Without the session entry, the user's ticket cache will not be
+created properly for ssh logins (among possibly others).
+
+If your users should normally all use Kerberos passwords exclusively,
+putting something like:
+
+```
+    password sufficient pam_krb5.so minimum_uid=1000
+    password required   pam_unix.so try_first_pass obscure md5
+```
+
+in `/etc/pam.d/common-password` will change users' passwords in Kerberos
+by default and then only fall back on Unix if that doesn't work.  (You can
+make this tighter by using the more complex new-style PAM configuration.)
+If you instead want to synchronize local and Kerberos passwords and change
+them both at the same time, you can do something like:
+
+```
+    password required   pam_unix.so obscure sha512
+    password required   pam_krb5.so use_authtok minimum_uid=1000
+```
+
+If you have multiple environments that you want to synchronize and you
+don't want password changes to continue if the Kerberos password change
+fails, use the `clear_on_fail` option.  For example:
+
+```
+    password required   pam_krb5.so clear_on_fail minimum_uid=1000
+    password required   pam_unix.so use_authtok obscure sha512
+    password required   pam_smbpass.so use_authtok
+```
+
+In this case, if `pam_krb5` cannot change the password (due to password
+strength rules on the KDC, for example), it will clear the stored password
+(because of the `clear_on_fail` option), and since `pam_unix` and
+`pam_smbpass` are both configured with `use_authtok`, they will both fail.
+`clear_on_fail` is not the default because it would interfere with the
+more common pattern of falling back to local passwords if the user doesn't
+exist in Kerberos.
+
+If you use a more complex configuration with the Linux PAM `[]` syntax for
+the session and account groups, note that `pam_krb5` returns a status of
+ignore, not success, if the user didn't log on with Kerberos.  You may
+need to handle that explicitly with `ignore=ignore` in your action list.
+
+There are many, many other possibilities.  See the Linux PAM documentation
+for all the configuration options.
+
+On Red Hat systems, modify `/etc/pam.d/system-auth` instead, which
+contains all of the configuration for the different stacks.
+
+You can also use pam-krb5 only for specific services.  In that case,
+modify the files in `/etc/pam.d` for that particular service to use
+`pam_krb5.so` for authentication.  For services that are using passwords
+over TLS to authenticate users, you may want to use the `ignore_k5login`
+and `no_ccache` options to the authenticate module.  `.k5login`
+authorization is only meaningful for local accounts and ticket caches are
+usually (although not always) only useful for interactive sessions.
+
+Configuring the module for Solaris is both simpler and less flexible,
+since Solaris (at least Solaris 8 and 9, which are the last versions of
+Solaris with which this module was extensively tested) use a single
+`/etc/pam.conf` file that contains configuration for all programs.  For
+console login on Solaris, try something like:
+
+```
+    login auth sufficient /usr/local/lib/security/pam_krb5.so minimum_uid=100
+    login auth required /usr/lib/security/pam_unix_auth.so.1 use_first_pass
+    login account required /usr/local/lib/security/pam_krb5.so minimum_uid=100
+    login account required /usr/lib/security/pam_unix_account.so.1
+    login session required /usr/local/lib/security/pam_krb5.so retain_after_close minimum_uid=100
+    login session required /usr/lib/security/pam_unix_session.so.1
+```
+
+A similar configuration could be used for other services, such as ssh.
+See the pam.conf(5) man page for more information.  When using this module
+with Solaris login (at least on Solaris 8 and 9), you will probably also
+need to add `retain_after_close` to the PAM configuration to avoid having
+the user's credentials deleted before they are logged in.
+
+The Solaris Kerberos library reportedly does not support prompting for a
+password change of an expired account during authentication.  Supporting
+password change for expired accounts on Solaris with native Kerberos may
+therefore require setting the `defer_pwchange` or `force_pwchange` option
+for selected login applications.  See the description and warnings about
+that option in the pam_krb5(5) man page.
+
+Some configuration options may be put in the `krb5.conf` file used by your
+Kerberos libraries (usually `/etc/krb5.conf` or
+`/usr/local/etc/krb5.conf`) instead or in addition to the PAM
+configuration.  See the man page for more details.
+
+The Kerberos library, via pam-krb5, will prompt the user to change their
+password if their password is expired, but when using OpenSSH, this will
+only work when `ChallengeResponseAuthentication` is enabled.  Unless this
+option is enabled, OpenSSH doesn't pass PAM messages to the user and can
+only respond to a simple password prompt.
+
+If you are using MIT Kerberos, be aware that users whose passwords are
+expired will not be prompted to change their password unless the KDC
+configuration for your realm in `[realms]` in `krb5.conf` contains a
+`master_kdc` setting or, if using DNS SRV records, you have a DNS entry
+for `_kerberos-master` as well as `_kerberos`.
diff --git a/t/data/update/pam-krb5/old/sections/debugging b/t/data/update/pam-krb5/old/sections/debugging
new file mode 100644
index 0000000..578fab0
--- /dev/null
+++ b/t/data/update/pam-krb5/old/sections/debugging
@@ -0,0 +1,28 @@
+The first step when debugging any problems with this module is to add
+`debug` to the PAM options for the module (either in the PAM configuration
+or in `krb5.conf`).  This will significantly increase the logging from the
+module and should provide a trace of exactly what failed and any available
+error information.
+
+Many Kerberos authentication problems are due to configuration issues in
+`krb5.conf`.  If pam-krb5 doesn't work, first check that `kinit` works on
+the same system.  That will test your basic Kerberos configuration.  If
+the system has a keytab file installed that's readable by the process
+doing authentication via PAM, make sure that the keytab is current and
+contains a key for `host/<system>` where <system> is the fully-qualified
+hostname.  pam-krb5 prevents KDC spoofing by checking the user's
+credentials when possible, but this means that if a keytab is present it
+must be correct or authentication will fail.  You can check the keytab
+with `klist -k` and `kinit -k`.
+
+Be sure that all libraries and modules, including PAM modules, loaded by a
+program use the same Kerberos libraries.  Sometimes programs that use PAM,
+such as current versions of OpenSSH, also link against Kerberos directly.
+If your sshd is linked against one set of Kerberos libraries and pam-krb5
+is linked against a different set of Kerberos libraries, this will often
+cause problems (such as segmentation faults, bus errors, assertions, or
+other strange behavior).  Similar issues apply to the com_err library or
+any other library used by both modules and shared libraries and by the
+application that loads them.  If your OS ships Kerberos libraries, it's
+usually best if possible to build all Kerberos software on the system
+against those libraries.
diff --git a/t/data/update/pam-krb5/old/sections/history-and-acknowledgements b/t/data/update/pam-krb5/old/sections/history-and-acknowledgements
new file mode 100644
index 0000000..0e6143e
--- /dev/null
+++ b/t/data/update/pam-krb5/old/sections/history-and-acknowledgements
@@ -0,0 +1,36 @@
+Originally written by Frank Cusack <fcusack@fcusack.com>, with the
+following acknowledgement:
+
+> Thanks to Naomaru Itoi <itoi@eecs.umich.edu>, Curtis King
+> <curtis.king@cul.ca>, and Derrick Brashear <shadow@dementia.org>, all of
+> whom have written and made available Kerberos 4/5 modules.  Although no
+> code in this module is directly from these author's modules, (except the
+> get_user_info() routine in support.c; derived from whichever of these
+> authors originally wrote the first module the other 2 copied from), it
+> was extremely helpful to look over their code which aided in my design.
+
+The module was then patched for the FreeBSD ports collection with
+additional modifications by unknown maintainers and then was modified by
+Joel Kociolek <joko@logidee.com> to be usable with Debian GNU/Linux.
+
+It was packaged by Sam Hartman as the Kerberos v5 PAM module for Debian
+and improved and modified by him and later by Russ Allbery to fix bugs and
+add additional features.  It was then adopted by Andres Salomon, who added
+support for refreshing credentials.
+
+The current distribution is maintained by Russ Allbery, who also added
+support for reading configuration from `krb5.conf`, added many features
+for compatibility with the Sourceforge module, commented and standardized
+the formatting of the code, and overhauled the documentation.
+
+Thanks to Douglas E. Engert for the initial implementation of PKINIT
+support.  I have since modified and reworked it extensively, so any bugs
+or compilation problems are my fault.
+
+Thanks to Markus Moeller for lots of debugging and multiple patches and
+suggestions for improved portability.
+
+Thanks to Booker Bense for the implementation of the `alt_auth_map`
+option.
+
+Thanks to Sam Hartman for the FAST support implementation.
diff --git a/t/data/update/pam-krb5/old/sections/implementation-notes b/t/data/update/pam-krb5/old/sections/implementation-notes
new file mode 100644
index 0000000..69f8338
--- /dev/null
+++ b/t/data/update/pam-krb5/old/sections/implementation-notes
@@ -0,0 +1,135 @@
+The normal sequence of actions taken for a user login is:
+
+```
+    pam_authenticate
+    pam_setcred(PAM_ESTABLISH_CRED)
+    pam_open_session
+    pam_acct_mgmt
+```
+
+and then at logout:
+
+```
+    pam_close_session
+```
+
+followed by closing the open PAM session.  The corresponding `pam_sm_*`
+functions in this module are called when an application calls those public
+interface functions.  Not all applications call all of those functions, or
+in particularly that order, although `pam_authenticate` is always first
+and has to be.
+
+When `pam_authenticate` is called, pam-krb5 creates a temporary ticket
+cache in `/tmp` and sets the PAM environment variable `PAM_KRB5CCNAME` to
+point to it.  This ticket cache will be automatically destroyed when the
+PAM session is closed and is there only to pass the initial credentials to
+the call to `pam_setcred`.  The module would use a memory cache, but
+memory caches will only work if the application preserves the PAM
+environment between the calls to `pam_authenticate` and `pam_setcred`.
+Most do, but OpenSSH notoriously does not and calls `pam_authenticate` in
+a subprocess, so this method is used to pass the tickets to the
+`pam_setcred` call in a different process.
+
+`pam_authenticate` does a complete authentication, including checking the
+resulting TGT by obtaining a service ticket for the local host if
+possible, but this requires read access to the system keytab.  If the
+keytab doesn't exist, can't be read, or doesn't include the appropriate
+credentials, the default is to accept the authentication.  This can be
+controlled by setting `verify_ap_req_nofail` to true in `[libdefaults]` in
+`/etc/krb5.conf`.  `pam_authenticate` also does a basic authorization
+check, by default calling `krb5_kuserok` (which uses `~/.k5login` if
+available and falls back to checking that the principal corresponds to the
+account name).  This can be customized with several options documented in
+the pam_krb5(5) man page.
+
+pam-krb5 treats `pam_open_session` and `pam_setcred(PAM_ESTABLISH_CRED)`
+as synonymous, as some applications call one and some call the other.
+Both copy the initial credentials from the temporary cache into a
+permanent cache for this session and set `KRB5CCNAME` in the environment.
+It will remember when the credential cache has been established and then
+avoid doing any duplicate work afterwards, since some applications call
+`pam_setcred` or `pam_open_session` multiple times (most notably X.Org 7
+and earlier xdm, which also throws away the module settings the last time
+it calls them).
+
+`pam_acct_mgmt` finds the ticket cache, reads it in to obtain the
+authenticated principal, and then does is another authorization check
+against `.k5login` or the local account name as described above.
+
+After the call to `pam_setcred` or `pam_open_session`, the ticket cache
+will be destroyed whenever the calling application either destroys the PAM
+environment or calls `pam_close_session`, which it should do on user
+logout.
+
+The normal sequence of events when refreshing a ticket cache (such as
+inside a screensaver) is:
+
+```
+    pam_authenticate
+    pam_setcred(PAM_REINITIALIZE_CRED)
+    pam_acct_mgmt
+```
+
+(`PAM_REFRESH_CRED` may be used instead.)  Authentication proceeds as
+above.  At the `pam_setcred` stage, rather than creating a new ticket
+cache, the module instead finds the current ticket cache (from the
+`KRB5CCNAME` environment variable or the default ticket cache location
+from the Kerberos library) and then reinitializes it with the credentials
+from the temporary `pam_authenticate` ticket cache.  When refreshing a
+ticket cache, the application should not open a session.  Calling
+`pam_acct_mgmt` is optional; pam-krb5 doesn't do anything different when
+it's called in this case.
+
+If `pam_authenticate` apparently didn't succeed, or if an account was
+configured to be ignored via `ignore_root` or `minimum_uid`, `pam_setcred`
+(and therefore `pam_open_session`) and `pam_acct_mgmt` return
+`PAM_IGNORE`, which tells the PAM library to proceed as if that module
+wasn't listed in the PAM configuration at all.  `pam_authenticate`,
+however, returns failure in the ignored user case by default, since
+otherwise a configuration using `ignore_root` with pam-krb5 as the only
+PAM module would allow anyone to log in as root without a password.  There
+doesn't appear to be a case where returning `PAM_IGNORE` instead would
+improve the module's behavior, but if you know of a case, please let me
+know.
+
+By default, `pam_authenticate` intentionally does not follow the PAM
+standard for handling expired accounts and instead returns failure from
+`pam_authenticate` unless the Kerberos libraries are able to change the
+account password during authentication.  Too many applications either do
+not call `pam_acct_mgmt` or ignore its exit status.  The fully correct PAM
+behavior (returning success from `pam_authenticate` and
+`PAM_NEW_AUTHTOK_REQD` from `pam_acct_mgmt`) can be enabled with the
+`defer_pwchange` option.
+
+The `defer_pwchange` option is unfortunately somewhat tricky to implement.
+In this case, the calling sequence is:
+
+```
+    pam_authenticate
+    pam_acct_mgmt
+    pam_chauthtok
+    pam_setcred
+    pam_open_session
+```
+
+During the first `pam_authenticate`, we can't obtain credentials and
+therefore a ticket cache since the password is expired.  But
+`pam_authenticate` isn't called again after `pam_chauthtok`, so
+`pam_chauthtok` has to create a ticket cache.  We however don't want it to
+do this for the normal password change (`passwd`) case.
+
+What we do is set a flag in our PAM data structure saying that we're
+processing an expired password, and `pam_chauthtok`, if it sees that flag,
+redoes the authentication with password prompting disabled after it
+finishes changing the password.
+
+Unfortunately, when handling password changes this way, `pam_chauthtok`
+will always have to prompt the user for their current password again even
+though they just typed it.  This is because the saved authentication
+tokens are cleared after `pam_authenticate` returns, for security reasons.
+We could hack around this by saving the password in our PAM data
+structure, but this would let the application gain access to it (exactly
+what the clearing is intended to prevent) and breaks a PAM library
+guarantee.  We could also work around this by having `pam_authenticate`
+get the `kadmin/changepw` authenticator in the expired password case and
+store it for `pam_chauthtok`, but it doesn't seem worth the hassle.
diff --git a/t/data/update/pam-krb5/old/test/prefix b/t/data/update/pam-krb5/old/test/prefix
new file mode 100644
index 0000000..3505fbc
--- /dev/null
+++ b/t/data/update/pam-krb5/old/test/prefix
@@ -0,0 +1,10 @@
+pam-krb5 comes with a comprehensive test suite, but it requires some
+configuration in order to test anything other than low-level utility
+functions.  For the full test suite, you will need to have a running KDC
+in which you can create two test accounts, one with admin access to the
+other.  Using a test KDC environment, if you have one, is recommended.
+
+Follow the instructions in `tests/config/README` to configure the test
+suite.
+
+Now, you can run the test suite with:
diff --git a/t/data/update/pam-krb5/old/test/suffix b/t/data/update/pam-krb5/old/test/suffix
new file mode 100644
index 0000000..4b1b8c8
--- /dev/null
+++ b/t/data/update/pam-krb5/old/test/suffix
@@ -0,0 +1,10 @@
+The default libkadm5clnt library on the system must match the
+implementation of your KDC for the module/expired test to work, since the
+two kadmin protocols are not compatible.  If you use the MIT library
+against a Heimdal server, the test will be skipped; if you use the Heimdal
+library against an MIT server, the test suite may hang.
+
+Several `module/expired` tests are expected to fail with Heimdal 1.5 due
+to a bug in Heimdal with reauthenticating immediately after a
+library-mediated password change of an expired password.  This is fixed in
+later releases of Heimdal.
diff --git a/t/data/update/remctl/docknot.yaml b/t/data/update/remctl/docknot.yaml
new file mode 100644
index 0000000..addf21e
--- /dev/null
+++ b/t/data/update/remctl/docknot.yaml
@@ -0,0 +1,381 @@
+---
+advisories:
+- date: 2018-04-01
+  threshold: '3.14'
+  versions: 3.12 and 3.13
+blurb: |
+  remctl is a client/server application that supports remote execution of
+  specific commands, using Kerberos GSS-API for authentication.
+  Authorization is controlled by a configuration file and ACL files and can
+  be set separately for each command, unlike with rsh.  remctl is like a
+  Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh
+  and sudo without most of the features and complexity of either.
+bootstrap: |
+  You will also need pkg-config installed to regenerate configure and
+  xml2rfc to build the formatted protocol documentation.
+build:
+  autoconf: '2.64'
+  automake: '1.11'
+  autotools: true
+  gssapi: true
+  install: true
+  kerberos: true
+  lancaster: true
+  manpages: true
+  middle: |
+    Solaris users should look at `examples/remctld.xml`, an SMF manifest for
+    running the `remctld` daemon.
+
+    To also build the Perl bindings for the libremctl client library, pass the
+    `--enable-perl` option to `configure`.  The Perl module build is handled
+    by the normal Perl extension build system, and therefore will be built
+    with compiler flags defined by your Perl installation and installed into
+    your local Perl module directory regardless of the `--prefix` argument to
+    `configure`.  To change this, you will need to run `perl Makefile.PL` in
+    the `perl` subdirectory of the build tree with appropriate options and
+    rebuild the module after running `make` and before running `make install`.
+
+    To also build the remctl PECL extension for PHP, pass the `--enable-php`
+    option to `configure`.  The PHP PECL module build is handled by the normal
+    PHP extension build system and therefore will be installed into your local
+    PHP module directory.  The configure script will look for `phpize` on your
+    `PATH` by default; if it's in some other directory, set the `PHPIZE`
+    environment variable to the full path or set it on the configure command
+    line.  The configure script for the PECL extension will be run during the
+    build instead of during configure.  This is unfortunately apparently
+    unavoidable given how the PECL build system works.
+
+    To also build the Python bindings for the libremctl client library, pass
+    the `--enable-python` option to configure.  The Python module build is
+    handled by the normal Python extension build system, and therefore will be
+    installed into your local Python module directory regardless of the
+    `--prefix` argument to `configure`.  To change this, you will need to run
+    `python setup.py install` by hand in the `python` directory with whatever
+    options you want to use.
+
+    To also build the Ruby bindings for the libremctl client library, pass
+    the `--enable-ruby` option to configure.  The Ruby module build is handled
+    by the normal Ruby module build system, and therefore will be installed
+    into your local Ruby module directory regardless of the `--prefix`
+    argument to `configure`.  To change this, override the `sitedir` variable on
+    the `make install` command line, as in:
+
+    ```
+        make install sitedir=/opt/ruby
+    ```
+
+    The remctl build system also supports a few other environment variables
+    that can be set to control aspects of the Perl, Python, and Ruby binding
+    build systems.  These are primarily only of use when packaging the
+    software.  For more information, a list of the variables, and their
+    effects, see the comment at the start of `Makefile.am`.
+
+    The Java client and server aren't integrated with the regular build
+    system.  For information on building and installing them, see
+    `java/README`.
+
+    remctl will use pkg-config if it's available to find the build flags for
+    libevent.  You can control which pkg-config binary and paths are used with
+    the normal pkg-config environment variables of `PKG_CONFIG`,
+    `PKG_CONFIG_PATH`, and `PKG_CONFIG_LIBDIR`, and you can override the
+    pkg-config results with `LIBEVENT_CFLAGS` and `LIBEVENT_LIBS`.
+    Alternately, you can bypass pkg-config by passing one or more of
+    `--with-libevent`, `--with-libevent-include`, and `--with-libevent-lib` to
+    indicate the install prefix, include directory, or library directory.
+
+    remctl will automatically build with PCRE support if pcre-config or the
+    PCRE library are found.  You can pass `--with-pcre` to configure to
+    specify the root directory where PCRE is installed, or set the include and
+    library directories separately with `--with-pcre-include` and
+    `--with-pcre-lib`.  You can also set `PCRE_CONFIG` to point to a different
+    pcre-config script, or do similar things as with `PATH_KRB5_CONFIG`
+    described below.
+
+    remctl will automatically build with GPUT support if the GPUT header and
+    library are found.  You can pass `--with-gput` to configure to specify the
+    root directory where GPUT is installed, or set the include and library
+    directories separately with `--with-gput-include` and `--with-gput-lib`.
+  reduced_depends: true
+  type: Autoconf
+copyrights:
+- holder: Russ Allbery <eagle@eyrie.org>
+  years: 2015-2016, 2018
+- holder: The Board of Trustees of the Leland Stanford Junior University
+  years: 2002-2014
+debian:
+  summary: |
+    Debian packages are available from Debian as of Debian 3.1 (sarge).  For
+    Debian 4.0 (etch) and later, install remctl-server for the server and
+    remctl-client for the client.  (The sarge release had a single remctl
+    package that contained both.)
+
+    The Net::Remctl Perl module is available in Debian 5.0 (lenny) and newer;
+    install libnet-remctl-perl for it.  The PHP bindings (php5-remctl), Python
+    bindings (python-remctl), and Ruby bindings (ruby-remctl) are available in
+    Debian 6.0 (squeeze) and newer.  The Ruby bindings package is named
+    libremctl-ruby in Debian versions before 7.0 (wheezy).
+description: |
+  remctl is a client/server application that supports remote execution of
+  specific commands, using Kerberos GSS-API for authentication and
+  confidentiality.  The commands a given user can execute are controlled by
+  a configuration file and ACL files and can easily be tightly limited,
+  unlike with rsh.  The mapping of command to backend program is done by the
+  configuration file, which allows some additional flexibility compared to
+  ssh command restrictions and works with Kerberos authentications rather
+  than being limited to public key authentications.
+
+  remctld is very similar to a CGI server that uses a different network
+  protocol than HTTP, always does strong authentication before executing the
+  desired command, and guarantees the data is encrypted on the network.
+  Alternately, you can think of it as a very simple combination of Kerberos
+  ssh and sudo, without most of the features of both but with simpler
+  authorization.
+
+  There are a lot of different client/server systems that do something
+  similar, including regular rsh, CGI, IBM's sysctl (not to be confused with
+  the Linux kernel call and configuration file of the same name), CERN's
+  arc, and more elaborate systems like MIT's Moira.  remctl has the
+  advantage over many of these schemes of using GSS-API and being about as
+  simple as it possibly can be while still being useful.  It doesn't require
+  any particular programming language, builds self-contained binaries, and
+  uses as minimal of a protocol as possible.
+
+  Both C and Java clients and servers are provided, as well as Perl, PHP,
+  and Python bindings for the C client library.  For more information about
+  the Java client, see `java/README`.  For more information about the PHP
+  bindings, see `php/README`.  For more information about the Python
+  bindings, see `python/README`.
+
+  Also included in the remctl package is an alternate way of running the
+  remctl server: remctl-shell.  This program is designed to be run as either
+  a shell or a forced command under ssh, using ssh for authentication and
+  communicating the authentication information to remctl-shell via either
+  environment variables or command-line arguments via the forced command
+  configuration.  This version of the server uses simple ssh clients, rather
+  than using the remctl client program or libraries.
+
+  remctl was originally written by Anton Ushakov as a replacement for IBM's
+  sysctl, a client/server application with Kerberos v4 authentication that
+  allowed the client to run Tcl code on the server, protected by ACLs.  At
+  Stanford, we used sysctl extensively, but mostly only to run external
+  programs, so remctl was developed as a Kerberos v5 equivalent that did
+  only the portions we needed.
+
+  Complete protocol documentation is available in `docs/protocol.html`.
+  Also present, as `docs/design.html`, is the original design document (now
+  somewhat out of date).
+distribution:
+  section: kerberos
+  tarname: remctl
+  version: remctl
+docs:
+  api:
+  - name: remctl-api
+    title: remctl and remctl_free_result
+  - name: remctl_new
+    title: remctl_new
+  - name: remctl_open
+    title: remctl_open
+  - name: remctl_command
+    title: remctl_command and remctl_commandv
+  - name: remctl_output
+    title: remctl_output
+  - name: remctl_noop
+    title: remctl_noop
+  - name: remctl_close
+    title: remctl_close
+  - name: remctl_error
+    title: remctl_error
+  - name: remctl_set_ccache
+    title: remctl_set_ccache
+  - name: remctl_set_source_ip
+    title: remctl_set_source_ip
+  - name: remctl_set_timeout
+    title: remctl_set_timeout
+  - name: net-remctl
+    title: Net::Remctl Perl module
+  - name: net-remctl-backend
+    title: Net::Remctl::Backend Perl module
+  developer:
+  - name: extending
+    title: Extending remctl
+  - name: protocol
+    title: Protocol specification
+  - name: protocol-v4
+    title: Protocol v4 draft
+  user:
+  - name: remctl
+    title: remctl manual page
+  - name: remctl-shell
+    title: remctl-shell manual page
+  - name: remctld
+    title: remctld manual page
+  - name: java-readme
+    title: Java client and server README
+  - name: php-readme
+    title: PHP bindings README
+  - name: python-readme
+    title: Python bindings README
+  - name: ruby-readme
+    title: Ruby bindings README
+  - name: thanks
+    title: Thanks and credits
+format: v1
+license:
+  name: Expat
+maintainer: Russ Allbery <eagle@eyrie.org>
+name: remctl
+packaging:
+  debian: remctl
+  extra: |
+    For those using Puppet, there is a
+    [Puppet module](https://forge.puppetlabs.com/ccin2p3/remctl)
+    available for installing the remctl server and managing server
+    configurations.  This was written and is maintained by the IN2P3 Computing
+    Centre; see that page for more information.
+quote:
+  author: Peter Marshall
+  text: |
+    Small deeds done are better than great deeds planned.
+readme:
+  sections:
+  - body: |
+      (These instructions are not tested by the author and are now dated.
+      Updated instructions via a pull request, issue, or email are very
+      welcome.)
+
+      First, install the Microsoft Windows SDK for Windows Vista if you have not
+      already.  This is a free download from Microsoft for users of "Genuine
+      Microsoft Windows."  The `vcvars32.bat` environment provided by Visual
+      Studio may work as an alternative, but has not been tested.
+
+      Next, install the [MIT Kerberos for Windows
+      SDK](https://web.mit.edu/kerberos/www/dist/index.html).  remctl has been
+      tested with version 3.2.1 but should hopefully work with later versions.
+
+      Then, follow these steps:
+
+      1. Run the `InitEnv.cmd` script included with the Windows SDK with
+         parameters `"/xp /release"`.
+
+      2. Run the `configure.bat` script, giving it as an argument the location
+         of the Kerberos for Windows SDK.  For example, if you installed the KfW
+         SDK in `"c:\KfW SDK"`, you should run:
+
+         ```
+             configure "c:\KfW SDK"
+         ```
+
+      3. Run `nmake` to start compiling.  You can ignore the warnings.
+
+      If all goes well, you will have `remctl.exe` and `remctl.dll`.  The latter
+      is a shared library used by the client program.  It exports the same
+      interface as the UNIX libremctl library.
+    title: Building on Windows
+requirements: |
+  The remctld server and the standard client are written in C and require a
+  C compiler and GSS-API libraries to build.  Both will build against either
+  MIT Kerberos or Heimdal of any reasonable vintage.  remctl will also build
+  against the Kerberos GSS-API implementation shipped with AIX 5.2 (and
+  possibly later versions) and the Solaris 10 generic GSS-API library (and
+  possibly later versions).  The `remctl_set_ccache` implementation is
+  improved by building with Kerberos libraries and a GSS-API library that
+  supports `gss_krb5_import_cred`.
+
+  The remctld server requires libevent 1.4.x or later.  It's only been
+  tested with libevent 1.4.13-stable and later, but should work with 1.4.4
+  or later.  It is now only tested with libevent 2.x, so moving to a later
+  version of libevent if possible is recommended.
+
+  The remctl server will support regex ACLs if the system supports the POSIX
+  regex API.  The remctl server also optionally supports PCRE regular
+  expressions in ACLs.  To include that support, the PCRE library is
+  required.
+
+  To build the remctl client for Windows, the Microsoft Windows SDK for
+  Windows Vista and the MIT Kerberos for Windows SDK are required, along
+  with a Microsoft Windows build environment (probably Visual Studio).
+  remctl has only been tested with the 3.2.1 MIT Kerberos for Windows SDK.
+  To run the resulting binary, MIT Kerberos for Windows must be installed
+  and configured.  The client was tested on Windows XP and Vista and should
+  work on Windows 2000 and up; however, the primary maintainer does not use
+  or test Windows, so it's always possible Windows support has broken.  The
+  server is not supported on Windows.
+
+  To build the Perl bindings for the C client library, you will need Perl
+  5.8 or later.
+
+  To build the PHP bindings for the C client library, you will need PHP 5.x
+  or later and phpize, plus any other programs that phpize requires.  PHP
+  5.x support has only been tested on 5.2 and 5.3, and PHP support is now
+  only tested on PHP 7.x and later.
+
+  To build the Python bindings for the C client library, you will need
+  Python 2.3 or later (primarily tested with Python 2.7).  Python 3 is not
+  (yet) supported.
+
+  To build the Ruby bindings for the C client library, you will need Ruby
+  1.8 or later (primarily tested with 2.5 and later).
+
+  None of the language bindings have been tested on Windows.
+
+  A Java client and Java server are available in the java subdirectory, but
+  they are not integrated into the normal build or built by default.  There
+  is a basic Makefile in that directory that may require some tweaking.  It
+  currently requires the Sun Java JDK (1.4.2, 5, or 6) or OpenJDK 6 or
+  later.  A considerably better Java client implementation is available on
+  the `java` branch in the Git repository but has not yet been merged.
+support:
+  email: eagle@eyrie.org
+  github: rra/remctl
+  web: https://www.eyrie.org/~eagle/software/remctl/
+synopsis: remote authenticated command execution with ACLs
+test:
+  prefix: |
+    remctl comes with a comprehensive test suite, but it requires some
+    configuration in order to test anything other than low-level utility
+    functions.  For the full test suite, you will need to have a keytab that
+    can authenticate to a running KDC.  Using a test KDC environment, if you
+    have one, is recommended.
+
+    Follow the instructions in `tests/config/README` to configure the test
+    suite.
+
+    Now, you can run the test suite with:
+  suffix: |
+    On particularly slow or loaded systems, you may see intermittent failures
+    from the `server/streaming` test because it's timing-sensitive.
+
+    The test suite will also need to be able to bind to 127.0.0.1 on port
+    11119 and 14373 to run test network server programs.
+
+    To test anonymous authentication, the KDC configured in the test suite
+    needs to support service tickets for the anonymous identity (not a
+    standard configuration).  This test will be skipped if the KDC does not
+    support this.
+
+    To test user handling in remctld, you will need the `fakeroot` command
+    (available in the `fakeroot` package in Debian and Ubuntu).  This test
+    will be skipped if `fakeroot` isn't available.
+
+    The following additional Perl modules will be used by the test suite for
+    the main package and the Perl bindings if installed:
+
+    * Test::MinimumVersion
+    * Test::Perl::Critic
+    * Test::Pod
+    * Test::Spelling
+    * Test::Strict
+    * Test::Synopsis
+
+    All are available on CPAN.  Those tests will be skipped if the modules are
+    not available.
+vcs:
+  browse: https://git.eyrie.org/?p=kerberos/remctl.git
+  github: rra/remctl
+  openhub: https://www.openhub.net/p/remctl
+  status:
+    travis: rra/remctl
+  type: Git
+  url: https://git.eyrie.org/git/kerberos/remctl.git
+version: '3.15'
diff --git a/t/data/update/remctl/old/blurb b/t/data/update/remctl/old/blurb
new file mode 100644
index 0000000..c062000
--- /dev/null
+++ b/t/data/update/remctl/old/blurb
@@ -0,0 +1,6 @@
+remctl is a client/server application that supports remote execution of
+specific commands, using Kerberos GSS-API for authentication.
+Authorization is controlled by a configuration file and ACL files and can
+be set separately for each command, unlike with rsh.  remctl is like a
+Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh
+and sudo without most of the features and complexity of either.
diff --git a/t/data/update/remctl/old/bootstrap b/t/data/update/remctl/old/bootstrap
new file mode 100644
index 0000000..0a018f7
--- /dev/null
+++ b/t/data/update/remctl/old/bootstrap
@@ -0,0 +1,2 @@
+You will also need pkg-config installed to regenerate configure and
+xml2rfc to build the formatted protocol documentation.
diff --git a/t/data/update/remctl/old/build/middle b/t/data/update/remctl/old/build/middle
new file mode 100644
index 0000000..4a2820f
--- /dev/null
+++ b/t/data/update/remctl/old/build/middle
@@ -0,0 +1,72 @@
+Solaris users should look at `examples/remctld.xml`, an SMF manifest for
+running the `remctld` daemon.
+
+To also build the Perl bindings for the libremctl client library, pass the
+`--enable-perl` option to `configure`.  The Perl module build is handled
+by the normal Perl extension build system, and therefore will be built
+with compiler flags defined by your Perl installation and installed into
+your local Perl module directory regardless of the `--prefix` argument to
+`configure`.  To change this, you will need to run `perl Makefile.PL` in
+the `perl` subdirectory of the build tree with appropriate options and
+rebuild the module after running `make` and before running `make install`.
+
+To also build the remctl PECL extension for PHP, pass the `--enable-php`
+option to `configure`.  The PHP PECL module build is handled by the normal
+PHP extension build system and therefore will be installed into your local
+PHP module directory.  The configure script will look for `phpize` on your
+`PATH` by default; if it's in some other directory, set the `PHPIZE`
+environment variable to the full path or set it on the configure command
+line.  The configure script for the PECL extension will be run during the
+build instead of during configure.  This is unfortunately apparently
+unavoidable given how the PECL build system works.
+
+To also build the Python bindings for the libremctl client library, pass
+the `--enable-python` option to configure.  The Python module build is
+handled by the normal Python extension build system, and therefore will be
+installed into your local Python module directory regardless of the
+`--prefix` argument to `configure`.  To change this, you will need to run
+`python setup.py install` by hand in the `python` directory with whatever
+options you want to use.
+
+To also build the Ruby bindings for the libremctl client library, pass
+the `--enable-ruby` option to configure.  The Ruby module build is handled
+by the normal Ruby module build system, and therefore will be installed
+into your local Ruby module directory regardless of the `--prefix`
+argument to `configure`.  To change this, override the `sitedir` variable on
+the `make install` command line, as in:
+
+```
+    make install sitedir=/opt/ruby
+```
+
+The remctl build system also supports a few other environment variables
+that can be set to control aspects of the Perl, Python, and Ruby binding
+build systems.  These are primarily only of use when packaging the
+software.  For more information, a list of the variables, and their
+effects, see the comment at the start of `Makefile.am`.
+
+The Java client and server aren't integrated with the regular build
+system.  For information on building and installing them, see
+`java/README`.
+
+remctl will use pkg-config if it's available to find the build flags for
+libevent.  You can control which pkg-config binary and paths are used with
+the normal pkg-config environment variables of `PKG_CONFIG`,
+`PKG_CONFIG_PATH`, and `PKG_CONFIG_LIBDIR`, and you can override the
+pkg-config results with `LIBEVENT_CFLAGS` and `LIBEVENT_LIBS`.
+Alternately, you can bypass pkg-config by passing one or more of
+`--with-libevent`, `--with-libevent-include`, and `--with-libevent-lib` to
+indicate the install prefix, include directory, or library directory.
+
+remctl will automatically build with PCRE support if pcre-config or the
+PCRE library are found.  You can pass `--with-pcre` to configure to
+specify the root directory where PCRE is installed, or set the include and
+library directories separately with `--with-pcre-include` and
+`--with-pcre-lib`.  You can also set `PCRE_CONFIG` to point to a different
+pcre-config script, or do similar things as with `PATH_KRB5_CONFIG`
+described below.
+
+remctl will automatically build with GPUT support if the GPUT header and
+library are found.  You can pass `--with-gput` to configure to specify the
+root directory where GPUT is installed, or set the include and library
+directories separately with `--with-gput-include` and `--with-gput-lib`.
diff --git a/t/data/update/remctl/old/debian/summary b/t/data/update/remctl/old/debian/summary
new file mode 100644
index 0000000..8316a52
--- /dev/null
+++ b/t/data/update/remctl/old/debian/summary
@@ -0,0 +1,10 @@
+Debian packages are available from Debian as of Debian 3.1 (sarge).  For
+Debian 4.0 (etch) and later, install remctl-server for the server and
+remctl-client for the client.  (The sarge release had a single remctl
+package that contained both.)
+
+The Net::Remctl Perl module is available in Debian 5.0 (lenny) and newer;
+install libnet-remctl-perl for it.  The PHP bindings (php5-remctl), Python
+bindings (python-remctl), and Ruby bindings (ruby-remctl) are available in
+Debian 6.0 (squeeze) and newer.  The Ruby bindings package is named
+libremctl-ruby in Debian versions before 7.0 (wheezy).
diff --git a/t/data/update/remctl/old/description b/t/data/update/remctl/old/description
new file mode 100644
index 0000000..09aff27
--- /dev/null
+++ b/t/data/update/remctl/old/description
@@ -0,0 +1,49 @@
+remctl is a client/server application that supports remote execution of
+specific commands, using Kerberos GSS-API for authentication and
+confidentiality.  The commands a given user can execute are controlled by
+a configuration file and ACL files and can easily be tightly limited,
+unlike with rsh.  The mapping of command to backend program is done by the
+configuration file, which allows some additional flexibility compared to
+ssh command restrictions and works with Kerberos authentications rather
+than being limited to public key authentications.
+
+remctld is very similar to a CGI server that uses a different network
+protocol than HTTP, always does strong authentication before executing the
+desired command, and guarantees the data is encrypted on the network.
+Alternately, you can think of it as a very simple combination of Kerberos
+ssh and sudo, without most of the features of both but with simpler
+authorization.
+
+There are a lot of different client/server systems that do something
+similar, including regular rsh, CGI, IBM's sysctl (not to be confused with
+the Linux kernel call and configuration file of the same name), CERN's
+arc, and more elaborate systems like MIT's Moira.  remctl has the
+advantage over many of these schemes of using GSS-API and being about as
+simple as it possibly can be while still being useful.  It doesn't require
+any particular programming language, builds self-contained binaries, and
+uses as minimal of a protocol as possible.
+
+Both C and Java clients and servers are provided, as well as Perl, PHP,
+and Python bindings for the C client library.  For more information about
+the Java client, see `java/README`.  For more information about the PHP
+bindings, see `php/README`.  For more information about the Python
+bindings, see `python/README`.
+
+Also included in the remctl package is an alternate way of running the
+remctl server: remctl-shell.  This program is designed to be run as either
+a shell or a forced command under ssh, using ssh for authentication and
+communicating the authentication information to remctl-shell via either
+environment variables or command-line arguments via the forced command
+configuration.  This version of the server uses simple ssh clients, rather
+than using the remctl client program or libraries.
+
+remctl was originally written by Anton Ushakov as a replacement for IBM's
+sysctl, a client/server application with Kerberos v4 authentication that
+allowed the client to run Tcl code on the server, protected by ACLs.  At
+Stanford, we used sysctl extensively, but mostly only to run external
+programs, so remctl was developed as a Kerberos v5 equivalent that did
+only the portions we needed.
+
+Complete protocol documentation is available in `docs/protocol.html`.
+Also present, as `docs/design.html`, is the original design document (now
+somewhat out of date).
diff --git a/t/data/update/remctl/old/metadata.json b/t/data/update/remctl/old/metadata.json
new file mode 100644
index 0000000..ebb63c7
--- /dev/null
+++ b/t/data/update/remctl/old/metadata.json
@@ -0,0 +1,171 @@
+{
+    "name": "remctl",
+    "version": "3.15",
+    "synopsis": "remote authenticated command execution with ACLs",
+    "maintainer": "Russ Allbery <eagle@eyrie.org>",
+    "copyrights": [
+        {
+            "holder": "Russ Allbery <eagle@eyrie.org>",
+            "years": "2015-2016, 2018",
+        },
+        {
+            "holder": "The Board of Trustees of the Leland Stanford Junior University",
+            "years": "2002-2014",
+        },
+    ],
+    "license": "Expat",
+    "build": {
+        "autotools": true,
+        "automake": "1.11",
+        "autoconf": "2.64",
+        "gssapi": true,
+        "install": true,
+        "kerberos": true,
+        "lancaster": true,
+        "manpages": true,
+        "reduced_depends": true,
+        "type": "Autoconf",
+    },
+    "support": {
+        "email": "eagle@eyrie.org",
+        "github": "rra/remctl",
+        "web": "https://www.eyrie.org/~eagle/software/remctl/",
+    },
+    "vcs": {
+        "type": "Git",
+        "url": "https://git.eyrie.org/git/kerberos/remctl.git",
+        "browse": "https://git.eyrie.org/?p=kerberos/remctl.git",
+        "github": "rra/remctl",
+        "openhub": "https://www.openhub.net/p/remctl",
+        "status": {
+            "travis": "rra/remctl",
+        },
+    },
+    "readme": {
+        "sections": [
+            { "title": "Building on Windows" },
+        ],
+    },
+    "quote": {
+        "author": "Peter Marshall",
+    },
+    "distribution": {
+        "section": "kerberos",
+        "tarname": "remctl",
+        "version": "remctl",
+    },
+    "packaging": {
+        "debian": "remctl",
+    },
+    "advisories": [
+        {
+            "date": "2018-04-01",
+            "versions": "3.12 and 3.13",
+            "threshold": "3.14",
+        },
+    ],
+    "docs": {
+        "user": [
+            {
+                "name": "remctl",
+                "title": "remctl manual page",
+            },
+            {
+                "name": "remctl-shell",
+                "title": "remctl-shell manual page",
+            },
+            {
+                "name": "remctld",
+                "title": "remctld manual page",
+            },
+            {
+                "name": "java-readme",
+                "title": "Java client and server README",
+            },
+            {
+                "name": "php-readme",
+                "title": "PHP bindings README",
+            },
+            {
+                "name": "python-readme",
+                "title": "Python bindings README",
+            },
+            {
+                "name": "ruby-readme",
+                "title": "Ruby bindings README",
+            },
+            {
+                "name": "thanks",
+                "title": "Thanks and credits",
+            },
+        ],
+        "developer": [
+            {
+                "name": "extending",
+                "title": "Extending remctl",
+            },
+            {
+                "name": "protocol",
+                "title": "Protocol specification",
+            },
+            {
+                "name": "protocol-v4",
+                "title": "Protocol v4 draft",
+            },
+        ],
+        "api": [
+            {
+                "name": "remctl-api",
+                "title": "remctl and remctl_free_result",
+            },
+            {
+                "name": "remctl_new",
+                "title": "remctl_new",
+            },
+            {
+                "name": "remctl_open",
+                "title": "remctl_open",
+            },
+            {
+                "name": "remctl_command",
+                "title": "remctl_command and remctl_commandv",
+            },
+            {
+                "name": "remctl_output",
+                "title": "remctl_output",
+            },
+            {
+                "name": "remctl_noop",
+                "title": "remctl_noop",
+            },
+            {
+                "name": "remctl_close",
+                "title": "remctl_close",
+            },
+            {
+                "name": "remctl_error",
+                "title": "remctl_error",
+            },
+            {
+                "name": "remctl_set_ccache",
+                "title": "remctl_set_ccache",
+            },
+            {
+                "name": "remctl_set_source_ip",
+                "title": "remctl_set_source_ip",
+            },
+            {
+                "name": "remctl_set_timeout",
+                "title": "remctl_set_timeout",
+            },
+            {
+                "name": "net-remctl",
+                "title": "Net::Remctl Perl module",
+            },
+            {
+                "name": "net-remctl-backend",
+                "title": "Net::Remctl::Backend Perl module",
+            },
+        ],
+    },
+}
diff --git a/t/data/update/remctl/old/packaging/extra b/t/data/update/remctl/old/packaging/extra
new file mode 100644
index 0000000..2be114e
--- /dev/null
+++ b/t/data/update/remctl/old/packaging/extra
@@ -0,0 +1,5 @@
+For those using Puppet, there is a
+[Puppet module](https://forge.puppetlabs.com/ccin2p3/remctl)
+available for installing the remctl server and managing server
+configurations.  This was written and is maintained by the IN2P3 Computing
+Centre; see that page for more information.
diff --git a/t/data/update/remctl/old/quote b/t/data/update/remctl/old/quote
new file mode 100644
index 0000000..f832afb
--- /dev/null
+++ b/t/data/update/remctl/old/quote
@@ -0,0 +1 @@
+Small deeds done are better than great deeds planned.
diff --git a/t/data/update/remctl/old/requirements b/t/data/update/remctl/old/requirements
new file mode 100644
index 0000000..83bc59e
--- /dev/null
+++ b/t/data/update/remctl/old/requirements
@@ -0,0 +1,52 @@
+The remctld server and the standard client are written in C and require a
+C compiler and GSS-API libraries to build.  Both will build against either
+MIT Kerberos or Heimdal of any reasonable vintage.  remctl will also build
+against the Kerberos GSS-API implementation shipped with AIX 5.2 (and
+possibly later versions) and the Solaris 10 generic GSS-API library (and
+possibly later versions).  The `remctl_set_ccache` implementation is
+improved by building with Kerberos libraries and a GSS-API library that
+supports `gss_krb5_import_cred`.
+
+The remctld server requires libevent 1.4.x or later.  It's only been
+tested with libevent 1.4.13-stable and later, but should work with 1.4.4
+or later.  It is now only tested with libevent 2.x, so moving to a later
+version of libevent if possible is recommended.
+
+The remctl server will support regex ACLs if the system supports the POSIX
+regex API.  The remctl server also optionally supports PCRE regular
+expressions in ACLs.  To include that support, the PCRE library is
+required.
+
+To build the remctl client for Windows, the Microsoft Windows SDK for
+Windows Vista and the MIT Kerberos for Windows SDK are required, along
+with a Microsoft Windows build environment (probably Visual Studio).
+remctl has only been tested with the 3.2.1 MIT Kerberos for Windows SDK.
+To run the resulting binary, MIT Kerberos for Windows must be installed
+and configured.  The client was tested on Windows XP and Vista and should
+work on Windows 2000 and up; however, the primary maintainer does not use
+or test Windows, so it's always possible Windows support has broken.  The
+server is not supported on Windows.
+
+To build the Perl bindings for the C client library, you will need Perl
+5.8 or later.
+
+To build the PHP bindings for the C client library, you will need PHP 5.x
+or later and phpize, plus any other programs that phpize requires.  PHP
+5.x support has only been tested on 5.2 and 5.3, and PHP support is now
+only tested on PHP 7.x and later.
+
+To build the Python bindings for the C client library, you will need
+Python 2.3 or later (primarily tested with Python 2.7).  Python 3 is not
+(yet) supported.
+
+To build the Ruby bindings for the C client library, you will need Ruby
+1.8 or later (primarily tested with 2.5 and later).
+
+None of the language bindings have been tested on Windows.
+
+A Java client and Java server are available in the java subdirectory, but
+they are not integrated into the normal build or built by default.  There
+is a basic Makefile in that directory that may require some tweaking.  It
+currently requires the Sun Java JDK (1.4.2, 5, or 6) or OpenJDK 6 or
+later.  A considerably better Java client implementation is available on
+the `java` branch in the Git repository but has not yet been merged.
diff --git a/t/data/update/remctl/old/sections/building-on-windows b/t/data/update/remctl/old/sections/building-on-windows
new file mode 100644
index 0000000..3a08d3d
--- /dev/null
+++ b/t/data/update/remctl/old/sections/building-on-windows
@@ -0,0 +1,31 @@
+(These instructions are not tested by the author and are now dated.
+Updated instructions via a pull request, issue, or email are very
+welcome.)
+
+First, install the Microsoft Windows SDK for Windows Vista if you have not
+already.  This is a free download from Microsoft for users of "Genuine
+Microsoft Windows."  The `vcvars32.bat` environment provided by Visual
+Studio may work as an alternative, but has not been tested.
+
+Next, install the [MIT Kerberos for Windows
+SDK](https://web.mit.edu/kerberos/www/dist/index.html).  remctl has been
+tested with version 3.2.1 but should hopefully work with later versions.
+
+Then, follow these steps:
+
+1. Run the `InitEnv.cmd` script included with the Windows SDK with
+   parameters `"/xp /release"`.
+
+2. Run the `configure.bat` script, giving it as an argument the location
+   of the Kerberos for Windows SDK.  For example, if you installed the KfW
+   SDK in `"c:\KfW SDK"`, you should run:
+
+   ```
+       configure "c:\KfW SDK"
+   ```
+
+3. Run `nmake` to start compiling.  You can ignore the warnings.
+
+If all goes well, you will have `remctl.exe` and `remctl.dll`.  The latter
+is a shared library used by the client program.  It exports the same
+interface as the UNIX libremctl library.
diff --git a/t/data/update/remctl/old/test/prefix b/t/data/update/remctl/old/test/prefix
new file mode 100644
index 0000000..1afd097
--- /dev/null
+++ b/t/data/update/remctl/old/test/prefix
@@ -0,0 +1,10 @@
+remctl comes with a comprehensive test suite, but it requires some
+configuration in order to test anything other than low-level utility
+functions.  For the full test suite, you will need to have a keytab that
+can authenticate to a running KDC.  Using a test KDC environment, if you
+have one, is recommended.
+
+Follow the instructions in `tests/config/README` to configure the test
+suite.
+
+Now, you can run the test suite with:
diff --git a/t/data/update/remctl/old/test/suffix b/t/data/update/remctl/old/test/suffix
new file mode 100644
index 0000000..f7ef8c7
--- /dev/null
+++ b/t/data/update/remctl/old/test/suffix
@@ -0,0 +1,27 @@
+On particularly slow or loaded systems, you may see intermittent failures
+from the `server/streaming` test because it's timing-sensitive.
+
+The test suite will also need to be able to bind to 127.0.0.1 on port
+11119 and 14373 to run test network server programs.
+
+To test anonymous authentication, the KDC configured in the test suite
+needs to support service tickets for the anonymous identity (not a
+standard configuration).  This test will be skipped if the KDC does not
+support this.
+
+To test user handling in remctld, you will need the `fakeroot` command
+(available in the `fakeroot` package in Debian and Ubuntu).  This test
+will be skipped if `fakeroot` isn't available.
+
+The following additional Perl modules will be used by the test suite for
+the main package and the Perl bindings if installed:
+
+* Test::MinimumVersion
+* Test::Perl::Critic
+* Test::Pod
+* Test::Spelling
+* Test::Strict
+* Test::Synopsis
+
+All are available on CPAN.  Those tests will be skipped if the modules are
+not available.
diff --git a/t/data/update/rra-c-util/docknot.yaml b/t/data/update/rra-c-util/docknot.yaml
new file mode 100644
index 0000000..ced18a0
--- /dev/null
+++ b/t/data/update/rra-c-util/docknot.yaml
@@ -0,0 +1,319 @@
+---
+blurb: |
+  rra-c-util is my collection of portability functions, utility functions,
+  Autoconf macros, and related shared C infrastructure, akin to gnulib but
+  without any GPL-covered code and additional support for Kerberos and PAM
+  development.  It serves as a common repository of code and infrastructure
+  used across multiple projects so that files have a canonical latest
+  version.  It's not intended for installation as a regular package;
+  instead, other packages are expected to copy files from here as needed.
+build:
+  autoconf: '2.64'
+  automake: '1.11'
+  autotools: true
+  lancaster: true
+  manpages: true
+copyrights:
+- holder: Russ Allbery <eagle@eyrie.org>
+  years: 2000, 2009-2010, 2013-2016
+- holder: The Board of Trustees of the Leland Stanford Junior University
+  years: 2009-2014
+description: |
+  The origins of this package are in the libinn utility library in INN.
+  Some of the utility and portability functions here are directly inspired
+  by or based on versions in older versions of INN, and I wrote and rewrote
+  considerable additional portability code and utility libraries when I took
+  over INN maintenance.  When I started maintaining other C packages, I
+  started copying pieces of libinn into those packages and merging it with
+  other portability and utility code.  Over time, each package gained a
+  slightly different version of various utility functions, replacements for
+  missing functions, and Autoconf macros.
+
+  The goal of this package is to merge all the various versions of any
+  portability or utility code that's used in more than one of my packages in
+  one place.  Then, each package can update to the latest rra-c-util version
+  before each release and gain from the improvements made for all other
+  packages.  You can think of it as my version of
+  [Gnulib](https://www.gnu.org/software/gnulib/), with everything released
+  under a permissive license (no GPL).
+
+  As well as C portability frameworks, Autoconf macros, and a general C
+  utility library, this package has also accumulated a considerable
+  collection of standard tests (for C and Perl packages) and a large library
+  of test utilities and support functions.  It also includes extensive
+  support for writing and testing PAM modules, and a portable implementation
+  of AFS PAGs.
+
+  This package uses the infrastructure of C TAP Harness for testing, but is
+  not the canonical version of `tests/runtests.c`, `tests/tap/basic.[ch]`,
+  `tests/tap/macros.h`, or `tests/tap/libtap.sh`.  Those files should be
+  pulled from [C TAP
+  Harness](https://www.eyrie.org/~eagle/software/c-tap-harness/) instead.
+distribution:
+  section: devel
+  tarname: rra-c-util
+  version: rra-c-util
+docs:
+  api:
+  - name: xmalloc
+    title: xmalloc, xcalloc, and xrealloc
+  extra:
+  - links:
+    - name: module-version
+      title: tests/perl/module-version-t
+    - name: module-version-perl
+      title: t/style/module-version.t
+    title: Test scripts
+  user:
+  - name: fakepam
+    title: PAM testing
+  - name: test-rra
+    title: Test::RRA
+  - name: test-rra-automake
+    title: Test::RRA::Automake
+  - name: test-rra-config
+    title: Test::RRA::Config
+  - name: test-rra-moduleversion
+    title: Test::RRA::ModuleVersion
+format: v1
+license:
+  name: Expat
+maintainer: Russ Allbery <eagle@eyrie.org>
+name: rra-c-util
+quote:
+  author: Phil Greenspun
+  text: |
+    Greenspun's Tenth Rule of Programming: any sufficiently complicated C or
+    Fortran program contains an ad hoc informally-specified bug-ridden slow
+    implementation of half of Common Lisp.
+readme:
+  sections:
+  - body: |
+      You can build rra-c-util with:
+
+      ```
+          ./configure
+          make
+      ```
+
+      Pass `--enable-kafs` to configure to attempt to build kafs support, which
+      will use either an existing libkafs or libkopenafs library or build the
+      kafs replacement included in this package.  You can also add
+      `--without-libkafs` to force the use of the internal kafs replacement.
+
+      Pass `--enable-silent-rules` to configure for a quieter build (similar to
+      the Linux kernel).  Use `make warnings` instead of make to build with full
+      GCC compiler warnings (requires a relatively current version of GCC).
+
+      Normally, configure will use `krb5-config` to determine the flags to use
+      to compile with your Kerberos libraries.  If `krb5-config` isn't found, it
+      will look for the standard Kerberos libraries in locations already
+      searched by your compiler.  If the the `krb5-config` script first in your
+      path is not the one corresponding to the Kerberos libraries you want to
+      use or if your Kerberos libraries and includes aren't in a location
+      searched by default by your compiler, you need to specify a different
+      Kerberos installation root via `--with-krb5=PATH`.  For example:
+
+      ```
+          ./configure --with-krb5=/usr/pubsw
+      ```
+
+      You can also individually set the paths to the include directory and the
+      library directory with `--with-krb5-include` and `--with-krb5-lib`.  You
+      may need to do this if Autoconf can't figure out whether to use `lib`,
+      `lib32`, or `lib64` on your platform.
+
+      To specify a particular `krb5-config` script to use, either set the
+      `PATH_KRB5_CONFIG` environment variable or pass it to configure like:
+
+      ```
+          ./configure PATH_KRB5_CONFIG=/path/to/krb5-config
+      ```
+
+      To not use `krb5-config` and force library probing even if there is a
+      `krb5-config` script on your path, set `PATH_KRB5_CONFIG` to a nonexistent
+      path:
+
+      ```
+          ./configure PATH_KRB5_CONFIG=/nonexistent
+      ```
+
+      `krb5-config` is not used and library probing is always done if either
+      `--with-krb5-include` or `--with-krb5-lib` are given.
+
+      GSS-API libraries are found the same way: with `krb5-config` by default if
+      it is found, and a `--with-gssapi=PATH` flag to specify the installation
+      root.  `PATH_KRB5_CONFIG` is similarly used to find krb5-config for the
+      GSS-API libraries, and `--with-gssapi-include` and `--with-gssapi-lib` can
+      be used to specify the exact paths, overriding any `krb5-config` results.
+    title: Building
+  - body: |
+      rra-c-util comes with an extensive test suite, which you can run after
+      building with:
+
+      ```
+          make check
+      ```
+
+      If a test fails, you can run a single test with verbose output via:
+
+      ```
+          tests/runtests -o <name-of-test>
+      ```
+
+      Do this instead of running the test program directly since it will ensure
+      that necessary environment variables are set up.
+    title: Testing
+  - body: |
+      While there is an install target, it's present only because Automake
+      provides it automatically.  Its use is not recommended.  Instead, the code
+      in this package is intended to be copied into your package and refreshed
+      from the latest release of rra-c-util for each release.
+
+      You can obviously copy the code and integrate it however works best for
+      your package and your build system.  Here's how I do it for my packages as
+      an example:
+
+      * Create a portable directory and copy `macros.h`, `system.h`,
+        `stdbool.h`, and `dummy.c` along with whatever additional functions that
+        your package uses that may not be present on all systems.  If you use
+        much of the `util` directory (see below), you'll need `asprintf.c`,
+        `reallocarray.c`, and `snprintf.c` at least.  If you use
+        `util/network.c`, you'll also need `getaddrinfo.c`, `getaddrinfo.h`,
+        `getnameinfo.c`, `getnameinfo.h`, `inet_*.c`, and `socket.h`.  You'll
+        need `winsock.c` for networking portability to Windows.
+
+      * Copy the necessary portions of `configure.ac` from this package into
+        your package.  `configure.ac` is commented to try to give you a guide
+        for what you need to copy over.  You will also need to make an `m4`
+        subdirectory, add the code to `configure.ac` to load Autoconf macros
+        from `m4`, and copy over `m4/snprintf.m4` and possibly `m4/socket.m4`
+        and `m4/inet-ntoa.m4`.
+
+      * Copy the code from `Makefile.am` for building `libportable.a` into your
+        package and be sure to link your package binaries with `libportable.a`.
+        If you include this code in a shared library, you'll need to build
+        `libportable.la` instead; see the Automake manual for the differences.
+        You'll need to change `LIBRARIES` to `LTLIBRARIES` and `LIBOBJS` to
+        `LTLIBOBJS` in addition to renaming the targets.
+
+      * Create a `util` directory and copy over the portions of the utility
+        library that you want.  You will probably need `messages.[ch]` and
+        `xmalloc.[ch]` if you copy anything over at all, since most of the rest
+        of the library uses those.  You will also need `m4/vamacros.m4` if you
+        use `messages.[ch]`.
+
+      * Copy the code from `Makefile.am` for building `libutil.a` into your
+        package and be sure to link your package binaries with `libutil.a`.  As
+        with `libportable.a`, if you want to use the utility functions in a
+        shared library, you'll need to instead build `libutil.la` and change
+        some of the Automake variables.
+
+      * If your package uses a TAP-based test suite written in C, consider using
+        the additional TAP utility functions in `tests/tap` (specifically
+        `messages.*`, `process.*`, and `string.*`).
+
+      * If you're using the Kerberos portability code, copy over
+        `portable/krb5.h`, `portable/krb5-extra.c`, `m4/krb5.m4`,
+        `m4/lib-depends.m4`, `m4/lib-pathname.m4`, and optionally
+        `util/messages-krb5.[ch]`.  You'll also need the relevant fragments of
+        `configure.ac`.  You may want to remove some things from `krb5.h` and
+        `krb5-extra.c` the corresponding configure checks if your code doesn't
+        need all of those functions.  If you need `krb5_get_renewed_creds`, also
+        copy over `krb5-renew.c`.  Don't forget to add `$(KRB5_CPPFLAGS)` to
+        `CPPFLAGS` for `libportable` and possibly `libutil`, and if you're
+        building a shared library, also add `$(KRB5_LDFLAGS)` to `LDFLAGS` and
+        `$(KRB5_LIBS)` to `LIBADD` for those libraries.
+
+        For a Kerberos-enabled test suite, also consider copying the
+        `kerberos.*` libraries in `tests/tap` for a Kerberos-enabled test suite.
+        If you want to use `kerberos_generate_conf` from `tests/tap/kerberos.c`,
+        also copy over `tests/data/generate-krb5-conf`.
+
+      * For testing that requires making Kerberos administrative changes,
+        consider copying over the `kadmin.*` libraries in `tests/tap`.
+
+      * For testing packages that use remctl, see the `tests/tap/remctl.c` and
+        `tests/tap/remctl.h` files for C tests and `tests/tap/remctl.sh` for
+        shell scripts.
+
+      * If you're using the kafs portability code, copy over the `kafs`
+        directory, `m4/kafs.m4`, `m4/lib-pathname.m4`, `portable/k_haspag.c`,
+        the code to build kafs from `Makefile.am`, and the relevant fragments of
+        `configure.ac`.
+
+      * If you're using the PAM portability code, copy over `pam-util/*`,
+        `portable/pam*`, `m4/pam-const.m4`, and the relevant fragments of
+        `configure.ac`.
+
+      * Copy over any other Autoconf macros that you want to use in your
+        package from the m4 directory.
+
+      * Copy over any generic tests from `tests/docs` and `tests/perl` that are
+        appropriate for your package.  If you use any of these, also copy over
+        the `tests/tap/perl` directory and `tests/data/perl.conf` (and customize
+        the latter for your package).
+
+      * If the package embeds a Perl module, copy over any tests from the
+        `perl/t` directory that are applicable.  This can provide generic
+        testing of the embedded Perl module using Perl's own test
+        infrastructure.  If you use any of these, also copy over the
+        `perl/t/data/perl.conf` file and customize it for your package.  You
+        will need to arrange for `perl/t/data` to contain copies of the
+        `perlcriticrc` and `perltidyrc` files, either by making copies of the
+        files from `tests/data` or by using make to copy them.
+
+      I also copy over all the relevant tests from the `tests` directory and the
+      build machinery for them from `Makefile.am` so that the portability and
+      utility layer are tested along with the rest of the package.  The test
+      driver should come from C TAP Harness.
+    title: Using This Code
+requirements: |
+  Everything requires a C compiler to build and expects an ISO C89 or later
+  C compiler and libraries.  Presence of strdup is also assumed, which is
+  guaranteed by POSIX 2008 but common in many earlier C libraries as well.
+  Otherwise, the files are meant to be copied into packages and the
+  requirements depend on which files one copies.
+
+  A Kerberos library, either MIT Kerberos or Heimdal, is required to build
+  this package as-is, since the Kerberos portability layer is built and
+  tested by default.  The other code will run fine without this requirement
+  when copied into other packages.
+
+  PAM libraries and headers are required to build the package as-is, since
+  the PAM supporting library is built and tested by default.  Other code can
+  be copied from this package without introducing a PAM dependency.
+
+  To build the the kafs portability layer, one of Linux, Mac OS X, Solaris
+  11, the kafs library that comes with either Heimdal or KTH Kerberos, the
+  kopenafs library that comes with newer OpenAFS, AFS header files (on any
+  other platform besides AIX or IRIX), or AFS libraries (on AIX and IRIX) is
+  required.  AIX binaries with AFS PAG support may not run on AIX systems
+  that do not have an AFS client installed due to how AIX handles system
+  calls.
+
+  To run the full test suite, and to use the Perl test support libraries,
+  Perl 5.6.2 or later is required.  The following additional Perl modules
+  will be used if present:
+
+  * IPC::System::Simple
+  * Test::MinimumVersion
+  * Test::Perl::Critic
+  * Test::Pod
+  * Test::Spelling
+  * Test::Strict
+
+  All are available on CPAN.  Those tests will be skipped if the modules are
+  not available.
+support:
+  email: eagle@eyrie.org
+  github: rra/rra-c-util
+  web: https://www.eyrie.org/~eagle/software/rra-c-util/
+synopsis: Russ Allbery's utility libraries for C
+vcs:
+  browse: https://git.eyrie.org/?p=devel/rra-c-util.git
+  github: rra/rra-c-util
+  openhub: https://www.openhub.net/p/rra-c-util
+  type: Git
+  url: https://git.eyrie.org/git/devel/rra-c-util.git
+version: '6.1'
diff --git a/t/data/update/rra-c-util/old/blurb b/t/data/update/rra-c-util/old/blurb
new file mode 100644
index 0000000..0e5f5ad
--- /dev/null
+++ b/t/data/update/rra-c-util/old/blurb
@@ -0,0 +1,7 @@
+rra-c-util is my collection of portability functions, utility functions,
+Autoconf macros, and related shared C infrastructure, akin to gnulib but
+without any GPL-covered code and additional support for Kerberos and PAM
+development.  It serves as a common repository of code and infrastructure
+used across multiple projects so that files have a canonical latest
+version.  It's not intended for installation as a regular package;
+instead, other packages are expected to copy files from here as needed.
diff --git a/t/data/update/rra-c-util/old/description b/t/data/update/rra-c-util/old/description
new file mode 100644
index 0000000..b6149b9
--- /dev/null
+++ b/t/data/update/rra-c-util/old/description
@@ -0,0 +1,30 @@
+The origins of this package are in the libinn utility library in INN.
+Some of the utility and portability functions here are directly inspired
+by or based on versions in older versions of INN, and I wrote and rewrote
+considerable additional portability code and utility libraries when I took
+over INN maintenance.  When I started maintaining other C packages, I
+started copying pieces of libinn into those packages and merging it with
+other portability and utility code.  Over time, each package gained a
+slightly different version of various utility functions, replacements for
+missing functions, and Autoconf macros.
+
+The goal of this package is to merge all the various versions of any
+portability or utility code that's used in more than one of my packages in
+one place.  Then, each package can update to the latest rra-c-util version
+before each release and gain from the improvements made for all other
+packages.  You can think of it as my version of
+[Gnulib](https://www.gnu.org/software/gnulib/), with everything released
+under a permissive license (no GPL).
+
+As well as C portability frameworks, Autoconf macros, and a general C
+utility library, this package has also accumulated a considerable
+collection of standard tests (for C and Perl packages) and a large library
+of test utilities and support functions.  It also includes extensive
+support for writing and testing PAM modules, and a portable implementation
+of AFS PAGs.
+
+This package uses the infrastructure of C TAP Harness for testing, but is
+not the canonical version of `tests/runtests.c`, `tests/tap/basic.[ch]`,
+`tests/tap/macros.h`, or `tests/tap/libtap.sh`.  Those files should be
+pulled from [C TAP
+Harness](https://www.eyrie.org/~eagle/software/c-tap-harness/) instead.
diff --git a/t/data/update/rra-c-util/old/metadata.json b/t/data/update/rra-c-util/old/metadata.json
new file mode 100644
index 0000000..7c56cf4
--- /dev/null
+++ b/t/data/update/rra-c-util/old/metadata.json
@@ -0,0 +1,96 @@
+{
+    "name": "rra-c-util",
+    "version": "6.1",
+    "synopsis": "Russ Allbery's utility libraries for C",
+    "maintainer": "Russ Allbery <eagle@eyrie.org>",
+    "copyrights": [
+        {
+            "holder": "Russ Allbery <eagle@eyrie.org>",
+            "years": "2000, 2009-2010, 2013-2016",
+        },
+        {
+            "holder": "The Board of Trustees of the Leland Stanford Junior University",
+            "years": "2009-2014",
+        },
+    ],
+    "license": "Expat",
+    "build": {
+        "lancaster": true,
+        "autotools": true,
+        "automake": "1.11",
+        "autoconf": "2.64",
+        "manpages": true,
+    },
+    "support": {
+        "email": "eagle@eyrie.org",
+        "github": "rra/rra-c-util",
+        "web": "https://www.eyrie.org/~eagle/software/rra-c-util/",
+    },
+    "vcs": {
+        "type": "Git",
+        "url": "https://git.eyrie.org/git/devel/rra-c-util.git",
+        "browse": "https://git.eyrie.org/?p=devel/rra-c-util.git",
+        "github": "rra/rra-c-util",
+        "openhub": "https://www.openhub.net/p/rra-c-util",
+    },
+    "readme": {
+        "sections": [
+            { "title": "Building" },
+            { "title": "Testing" },
+            { "title": "Using This Code" },
+        ],
+    },
+    "quote": {
+        "author": "Phil Greenspun",
+    },
+    "distribution": {
+        "section": "devel",
+        "tarname": "rra-c-util",
+        "version": "rra-c-util",
+    },
+    "docs": {
+        "user": [
+            {
+                "name": "fakepam",
+                "title": "PAM testing",
+            },
+            {
+                "name": "test-rra",
+                "title": "Test::RRA",
+            },
+            {
+                "name": "test-rra-automake",
+                "title": "Test::RRA::Automake",
+            },
+            {
+                "name": "test-rra-config",
+                "title": "Test::RRA::Config",
+            },
+            {
+                "name": "test-rra-moduleversion",
+                "title": "Test::RRA::ModuleVersion",
+            },
+        ],
+        "api": [
+            {
+                "name": "xmalloc",
+                "title": "xmalloc, xcalloc, and xrealloc",
+            },
+        ],
+        "extra": [
+            {
+                "title": "Test scripts",
+                "links": [
+                    {
+                        "name": "module-version",
+                        "title": "tests/perl/module-version-t",
+                    },
+                    {
+                        "name": "module-version-perl",
+                        "title": "t/style/module-version.t",
+                    },
+                ],
+            },
+        ],
+    },
+}
diff --git a/t/data/update/rra-c-util/old/quote b/t/data/update/rra-c-util/old/quote
new file mode 100644
index 0000000..56f2e6d
--- /dev/null
+++ b/t/data/update/rra-c-util/old/quote
@@ -0,0 +1,3 @@
+Greenspun's Tenth Rule of Programming: any sufficiently complicated C or
+Fortran program contains an ad hoc informally-specified bug-ridden slow
+implementation of half of Common Lisp.
diff --git a/t/data/update/rra-c-util/old/requirements b/t/data/update/rra-c-util/old/requirements
new file mode 100644
index 0000000..b9292f6
--- /dev/null
+++ b/t/data/update/rra-c-util/old/requirements
@@ -0,0 +1,36 @@
+Everything requires a C compiler to build and expects an ISO C89 or later
+C compiler and libraries.  Presence of strdup is also assumed, which is
+guaranteed by POSIX 2008 but common in many earlier C libraries as well.
+Otherwise, the files are meant to be copied into packages and the
+requirements depend on which files one copies.
+
+A Kerberos library, either MIT Kerberos or Heimdal, is required to build
+this package as-is, since the Kerberos portability layer is built and
+tested by default.  The other code will run fine without this requirement
+when copied into other packages.
+
+PAM libraries and headers are required to build the package as-is, since
+the PAM supporting library is built and tested by default.  Other code can
+be copied from this package without introducing a PAM dependency.
+
+To build the the kafs portability layer, one of Linux, Mac OS X, Solaris
+11, the kafs library that comes with either Heimdal or KTH Kerberos, the
+kopenafs library that comes with newer OpenAFS, AFS header files (on any
+other platform besides AIX or IRIX), or AFS libraries (on AIX and IRIX) is
+required.  AIX binaries with AFS PAG support may not run on AIX systems
+that do not have an AFS client installed due to how AIX handles system
+calls.
+
+To run the full test suite, and to use the Perl test support libraries,
+Perl 5.6.2 or later is required.  The following additional Perl modules
+will be used if present:
+
+* IPC::System::Simple
+* Test::MinimumVersion
+* Test::Perl::Critic
+* Test::Pod
+* Test::Spelling
+* Test::Strict
+
+All are available on CPAN.  Those tests will be skipped if the modules are
+not available.
diff --git a/t/data/update/rra-c-util/old/sections/building b/t/data/update/rra-c-util/old/sections/building
new file mode 100644
index 0000000..b604917
--- /dev/null
+++ b/t/data/update/rra-c-util/old/sections/building
@@ -0,0 +1,57 @@
+You can build rra-c-util with:
+
+```
+    ./configure
+    make
+```
+
+Pass `--enable-kafs` to configure to attempt to build kafs support, which
+will use either an existing libkafs or libkopenafs library or build the
+kafs replacement included in this package.  You can also add
+`--without-libkafs` to force the use of the internal kafs replacement.
+
+Pass `--enable-silent-rules` to configure for a quieter build (similar to
+the Linux kernel).  Use `make warnings` instead of make to build with full
+GCC compiler warnings (requires a relatively current version of GCC).
+
+Normally, configure will use `krb5-config` to determine the flags to use
+to compile with your Kerberos libraries.  If `krb5-config` isn't found, it
+will look for the standard Kerberos libraries in locations already
+searched by your compiler.  If the the `krb5-config` script first in your
+path is not the one corresponding to the Kerberos libraries you want to
+use or if your Kerberos libraries and includes aren't in a location
+searched by default by your compiler, you need to specify a different
+Kerberos installation root via `--with-krb5=PATH`.  For example:
+
+```
+    ./configure --with-krb5=/usr/pubsw
+```
+
+You can also individually set the paths to the include directory and the
+library directory with `--with-krb5-include` and `--with-krb5-lib`.  You
+may need to do this if Autoconf can't figure out whether to use `lib`,
+`lib32`, or `lib64` on your platform.
+
+To specify a particular `krb5-config` script to use, either set the
+`PATH_KRB5_CONFIG` environment variable or pass it to configure like:
+
+```
+    ./configure PATH_KRB5_CONFIG=/path/to/krb5-config
+```
+
+To not use `krb5-config` and force library probing even if there is a
+`krb5-config` script on your path, set `PATH_KRB5_CONFIG` to a nonexistent
+path:
+
+```
+    ./configure PATH_KRB5_CONFIG=/nonexistent
+```
+
+`krb5-config` is not used and library probing is always done if either
+`--with-krb5-include` or `--with-krb5-lib` are given.
+
+GSS-API libraries are found the same way: with `krb5-config` by default if
+it is found, and a `--with-gssapi=PATH` flag to specify the installation
+root.  `PATH_KRB5_CONFIG` is similarly used to find krb5-config for the
+GSS-API libraries, and `--with-gssapi-include` and `--with-gssapi-lib` can
+be used to specify the exact paths, overriding any `krb5-config` results.
diff --git a/t/data/update/rra-c-util/old/sections/testing b/t/data/update/rra-c-util/old/sections/testing
new file mode 100644
index 0000000..47cca20
--- /dev/null
+++ b/t/data/update/rra-c-util/old/sections/testing
@@ -0,0 +1,15 @@
+rra-c-util comes with an extensive test suite, which you can run after
+building with:
+
+```
+    make check
+```
+
+If a test fails, you can run a single test with verbose output via:
+
+```
+    tests/runtests -o <name-of-test>
+```
+
+Do this instead of running the test program directly since it will ensure
+that necessary environment variables are set up.
diff --git a/t/data/update/rra-c-util/old/sections/using-this-code b/t/data/update/rra-c-util/old/sections/using-this-code
new file mode 100644
index 0000000..0c9149a
--- /dev/null
+++ b/t/data/update/rra-c-util/old/sections/using-this-code
@@ -0,0 +1,102 @@
+While there is an install target, it's present only because Automake
+provides it automatically.  Its use is not recommended.  Instead, the code
+in this package is intended to be copied into your package and refreshed
+from the latest release of rra-c-util for each release.
+
+You can obviously copy the code and integrate it however works best for
+your package and your build system.  Here's how I do it for my packages as
+an example:
+
+* Create a portable directory and copy `macros.h`, `system.h`,
+  `stdbool.h`, and `dummy.c` along with whatever additional functions that
+  your package uses that may not be present on all systems.  If you use
+  much of the `util` directory (see below), you'll need `asprintf.c`,
+  `reallocarray.c`, and `snprintf.c` at least.  If you use
+  `util/network.c`, you'll also need `getaddrinfo.c`, `getaddrinfo.h`,
+  `getnameinfo.c`, `getnameinfo.h`, `inet_*.c`, and `socket.h`.  You'll
+  need `winsock.c` for networking portability to Windows.
+
+* Copy the necessary portions of `configure.ac` from this package into
+  your package.  `configure.ac` is commented to try to give you a guide
+  for what you need to copy over.  You will also need to make an `m4`
+  subdirectory, add the code to `configure.ac` to load Autoconf macros
+  from `m4`, and copy over `m4/snprintf.m4` and possibly `m4/socket.m4`
+  and `m4/inet-ntoa.m4`.
+
+* Copy the code from `Makefile.am` for building `libportable.a` into your
+  package and be sure to link your package binaries with `libportable.a`.
+  If you include this code in a shared library, you'll need to build
+  `libportable.la` instead; see the Automake manual for the differences.
+  You'll need to change `LIBRARIES` to `LTLIBRARIES` and `LIBOBJS` to
+  `LTLIBOBJS` in addition to renaming the targets.
+
+* Create a `util` directory and copy over the portions of the utility
+  library that you want.  You will probably need `messages.[ch]` and
+  `xmalloc.[ch]` if you copy anything over at all, since most of the rest
+  of the library uses those.  You will also need `m4/vamacros.m4` if you
+  use `messages.[ch]`.
+
+* Copy the code from `Makefile.am` for building `libutil.a` into your
+  package and be sure to link your package binaries with `libutil.a`.  As
+  with `libportable.a`, if you want to use the utility functions in a
+  shared library, you'll need to instead build `libutil.la` and change
+  some of the Automake variables.
+
+* If your package uses a TAP-based test suite written in C, consider using
+  the additional TAP utility functions in `tests/tap` (specifically
+  `messages.*`, `process.*`, and `string.*`).
+
+* If you're using the Kerberos portability code, copy over
+  `portable/krb5.h`, `portable/krb5-extra.c`, `m4/krb5.m4`,
+  `m4/lib-depends.m4`, `m4/lib-pathname.m4`, and optionally
+  `util/messages-krb5.[ch]`.  You'll also need the relevant fragments of
+  `configure.ac`.  You may want to remove some things from `krb5.h` and
+  `krb5-extra.c` the corresponding configure checks if your code doesn't
+  need all of those functions.  If you need `krb5_get_renewed_creds`, also
+  copy over `krb5-renew.c`.  Don't forget to add `$(KRB5_CPPFLAGS)` to
+  `CPPFLAGS` for `libportable` and possibly `libutil`, and if you're
+  building a shared library, also add `$(KRB5_LDFLAGS)` to `LDFLAGS` and
+  `$(KRB5_LIBS)` to `LIBADD` for those libraries.
+
+  For a Kerberos-enabled test suite, also consider copying the
+  `kerberos.*` libraries in `tests/tap` for a Kerberos-enabled test suite.
+  If you want to use `kerberos_generate_conf` from `tests/tap/kerberos.c`,
+  also copy over `tests/data/generate-krb5-conf`.
+
+* For testing that requires making Kerberos administrative changes,
+  consider copying over the `kadmin.*` libraries in `tests/tap`.
+
+* For testing packages that use remctl, see the `tests/tap/remctl.c` and
+  `tests/tap/remctl.h` files for C tests and `tests/tap/remctl.sh` for
+  shell scripts.
+
+* If you're using the kafs portability code, copy over the `kafs`
+  directory, `m4/kafs.m4`, `m4/lib-pathname.m4`, `portable/k_haspag.c`,
+  the code to build kafs from `Makefile.am`, and the relevant fragments of
+  `configure.ac`.
+
+* If you're using the PAM portability code, copy over `pam-util/*`,
+  `portable/pam*`, `m4/pam-const.m4`, and the relevant fragments of
+  `configure.ac`.
+
+* Copy over any other Autoconf macros that you want to use in your
+  package from the m4 directory.
+
+* Copy over any generic tests from `tests/docs` and `tests/perl` that are
+  appropriate for your package.  If you use any of these, also copy over
+  the `tests/tap/perl` directory and `tests/data/perl.conf` (and customize
+  the latter for your package).
+
+* If the package embeds a Perl module, copy over any tests from the
+  `perl/t` directory that are applicable.  This can provide generic
+  testing of the embedded Perl module using Perl's own test
+  infrastructure.  If you use any of these, also copy over the
+  `perl/t/data/perl.conf` file and customize it for your package.  You
+  will need to arrange for `perl/t/data` to contain copies of the
+  `perlcriticrc` and `perltidyrc` files, either by making copies of the
+  files from `tests/data` or by using make to copy them.
+
+I also copy over all the relevant tests from the `tests` directory and the
+build machinery for them from `Makefile.am` so that the portability and
+utility layer are tested along with the rest of the package.  The test
+driver should come from C TAP Harness.