docbook-utils

Overview

docbook-utils provides shell scripts for working with DocBook documents. In practice, it is used to convert DocBook content into other output formats and to compare SGML files. The package exists in the distribution so systems that still rely on DocBook toolchains have a packaged, reproducible way to use these utilities.

The package is mainly relevant to maintainers of documentation toolchains, build systems that process DocBook sources, and users who still work with legacy SGML-based documentation workflows.

Purpose and typical use cases

Typical uses include:

• converting DocBook sources into publishable formats
• comparing SGML documents as part of documentation review or build checks
• providing helper scripts for older or script-driven documentation pipelines
• supporting distribution packages that still need DocBook-based tooling during build time or at runtime

Typical users include:

• distribution maintainers
• documentation and release engineers
• build and CI/CD maintainers
• developers who need to process DocBook sources
• users maintaining older documentation archives or conversion workflows

Upstream project

Upstream project: devexp-db/docbook-utils

NiceOS maintainers should verify upstream state before each update, including whether the upstream repository layout, build inputs, or script behavior has changed in ways that affect packaging.

Dist-git repository contents

This RPM dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source metadata and manifest files used to track external sources
• METADATA/ — repository metadata maintained by the packaging workflow
• SBOM/ — software bill of materials artifacts when present

The repository contains packaging metadata, not the full upstream source tree.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository.

Instead, source integrity is tracked through manifest files in SOURCES/. Those manifests record what should be fetched for a build and allow maintainers to verify that the packaged source set matches the expected upstream inputs.

When updating the package, NiceOS maintainers should check that:

• the source manifests still match the intended upstream source set
• any changed upstream artifacts are reflected in the SOURCES/ metadata
• the spec file still points to the correct source layout and install paths
• no packaging files depend on a stale source arrangement

NiceOS maintenance notes

Before updating this package, review the following:

• upstream repository status and release/tag history
• whether any packaging patches are still needed or can be dropped
• whether file installation paths or script names changed upstream
• whether documentation or man-page generation steps need regeneration
• whether the package still builds cleanly on the target NiceOS branch
• whether the update changes behavior for existing DocBook workflows

Risks to consider:

• documentation toolchains can be sensitive to small script changes
• changes in upstream layout may break install or file lists
• legacy SGML/DocBook workflows may depend on behavior that is not obvious from a quick build
• any regenerated packaging metadata should be reviewed for accidental drift

If any of these points are unclear from the upstream sources, NiceOS maintainers should verify them before relying on the update.

Build and verification checklist

For RPM maintenance, a practical checklist is:

1. Review upstream changes and confirm they are relevant to the packaged scripts.
2. Verify that SOURCES/ manifests describe the intended source inputs.
3. Check whether the spec file needs patch refresh, path updates, or dependency adjustments.
4. Rebuild the package in a clean mock or equivalent build environment.
5. Inspect build logs for missing scripts, install-path mismatches, or packaging warnings.
6. Run any available file-list or ownership checks.
7. If the package ships documentation or helper scripts, verify they install to the expected locations.
8. Test the installed tools on a sample DocBook source if practical.
9. Review SBOM/ artifacts if your packaging workflow expects them to be regenerated.
10. Confirm that the final RPM contents match the intended package scope.

References

• Upstream project
• Package information

Russian documentation

• README_RU.md

Dist-git repository notes

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