docbook2X

Overview

docbook2X is a command-line toolset for converting DocBook documents into traditional Unix man pages and GNU Texinfo output. It is a small upstream project, so the package in NiceOS mainly exists to make that converter available in a distribution-friendly form for users and tooling that still rely on DocBook-based documentation workflows. (docbook2x.sourceforge.net)

Purpose and typical use cases

Typical uses include:

• generating man pages from DocBook sources during packaging or documentation builds;
• producing Texinfo output for projects that publish or install Info manuals;
• integrating DocBook conversion into build scripts, release tooling, or CI jobs;
• maintaining legacy documentation pipelines that already expect docbook2X-style commands and behavior. (docbook2x.sourceforge.net)

Typical users are:

• package maintainers and release engineers who need reproducible documentation builds;
• developers who keep documentation in DocBook and want command-line conversion;
• CI/CD maintainers who validate generated documentation artifacts;
• documentation-focused users who need man-page or Texinfo output from existing DocBook sources.

Upstream project

Upstream describes docbook2X as a software package that converts DocBook documents into man pages and Texinfo documents. The upstream site and SourceForge project page are the main references for the project and its documentation. NiceOS maintainers should verify any packaging assumptions against the upstream documentation before relying on them. (docbook2x.sourceforge.net)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source integrity metadata and manifests used by the package tooling;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when present.

The large upstream source archive is intentionally not stored in this Git repository. Instead, the repository keeps source-manifest metadata in SOURCES/ so maintainers can track what should be fetched and verified without committing bulky upstream tarballs into Git.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/. The repository does not need to store the upstream archive itself, and it does not need version-specific hash values in the README.

Before an update, NiceOS maintainers should verify that:

• the manifest entries still point to the intended upstream source;
• the fetched source matches the expected upstream release or snapshot;
• any required packaging metadata still matches the upstream layout;
• the source set has not changed in a way that requires new patches or spec updates.

NiceOS maintenance notes

Before updating this package, check the following:

• whether upstream documentation or build behavior changed in a way that affects the spec;
• whether patch files still apply cleanly;
• whether any file in SPECS/, SOURCES/, METADATA/, or SBOM/ needs regeneration or refresh;
• whether doc generation still works with current toolchain components used in NiceOS;
• whether the package still produces the expected commands and installed documentation artifacts.

Risk areas to consider:

• doc build failures caused by changes in external XML/XSLT tooling;
• stale packaging assumptions about file names, install paths, or helper scripts;
• regressions in generated man-page or Texinfo output;
• repository drift when upstream changes are mirrored imperfectly.

If any of these points are uncertain, NiceOS maintainers should verify them against the actual build logs and upstream documentation rather than assuming compatibility.

Build and verification checklist

For a normal RPM maintenance update, review the package with this checklist:

1. Confirm that the source manifests in SOURCES/ are correct.
2. Inspect the spec file for outdated patches or obsolete build logic.
3. Rebuild the SRPM and binary RPMs in a clean environment.
4. Check that the package installs the expected binaries, manuals, and auxiliary files.
5. Verify that generated man pages and Texinfo output still build correctly, if they are part of the package workflow.
6. Review build logs for dependency resolution issues, warnings, and documentation-generation failures.
7. Run any package-specific tests or smoke checks available in the packaging tree.
8. Confirm that repository metadata and SBOM material remain consistent after the update.

References

• docbook2X home page
• docbook2X documentation table of contents
• docbook2X SourceForge project page

Russian documentation

Read the Russian version here: README_RU.md

Dist-git repository notes

• Package repository: rpms/docbook2X
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.