docbook-dtds

Overview

DocBook is a structured markup vocabulary maintained by the OASIS DocBook Technical Committee. It is designed for books, manuals, articles, and other prose documents, especially technical documentation for software and hardware. The docbook-dtds package provides the DocBook DTD set so other packages can validate or process DocBook documents during builds and documentation workflows. (oasis-open.org)

Purpose and typical use cases

Typical uses include:

• validating DocBook SGML or XML documents in build systems,
• generating package manuals and technical documentation,
• supporting documentation toolchains that depend on DocBook DTD references,
• providing the schema files needed by documentation authors and tool maintainers.

Typical users are:

• distribution maintainers who package documentation tools,
• developers who build project manuals from DocBook sources,
• CI/CD maintainers who need reproducible documentation builds,
• documentation engineers and technical writers,
• security or compliance teams that verify documentation pipelines and artifact provenance.

Upstream project

Upstream DocBook is an OASIS project. OASIS describes DocBook as a DTD for computer documentation and notes that DocBook 4.5 and earlier versions are officially available as DTDs for both XML and SGML. The upstream documentation also states that DocBook is well suited to books and papers about computer hardware and software. (oasis-open.org)

If you need deeper format or compatibility details, NiceOS maintainers should verify the exact upstream release scope used by this package before relying on it.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic.
• SOURCES/ — source manifests and metadata used by the packaging workflow.
• METADATA/ — repository metadata used by the forge and packaging tooling.
• SBOM/ — software bill of materials data, when provided for the package.

The repository is meant to carry packaging inputs and 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/.

For maintainers, this means:

• verify that the manifest entries still point to the intended upstream content,
• confirm that any repacked or regenerated source material is expected,
• review the spec file for any source handling changes,
• avoid assuming that repository contents alone are sufficient to reproduce the upstream tarball.

Do not rely on mutable local state when reviewing a package update; the manifest files and spec file are the packaging record.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream content still matches the package role in the distribution,
• whether any source manifests in SOURCES/ need to be refreshed,
• whether the spec file still installs the correct DTD files and paths,
• whether documentation or file list changes require updates in %files, subpackages, or auxiliary packaging metadata,
• whether the SBOM, if present, needs regeneration,
• whether the update changes file layout, public identifiers, or downstream consumers.

Risks to consider:

• documentation toolchains may depend on exact DTD locations,
• small upstream changes can affect validation or installed references,
• repackaged sources may need careful review for completeness,
• packaging changes can break consumers even when upstream changes look minor.

Build and verification checklist

Use a basic RPM maintainer checklist:

1. Inspect the upstream change and confirm it is appropriate for this package.
2. Compare the new source material against the existing manifest entries in SOURCES/.
3. Review the spec file for path changes, file lists, and any custom install steps.
4. Build the package in a clean environment.
5. Verify that the expected DTD files are installed in the intended locations.
6. Check that ownership, permissions, and file lists are correct.
7. Run any available package tests or documentation validation steps.
8. Confirm that no unexpected files were added or removed.
9. Review generated metadata, including SBOM content if the repository maintains one.
10. Verify that dependent packages or documentation builds still resolve the DocBook references they expect.

References

• OASIS DocBook Technical Committee document repository
• OASIS DocBook specification overview
• DocBook 4.5 specification
• DocBook introduction and overview

Russian documentation

See README_RU.md for the Russian version of this document.

Dist-git repository notes

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