docbook5-style-xsl

Overview

docbook5-style-xsl packages the DocBook XSLT 1.0 stylesheets used to transform DocBook XML documents into deliverable formats such as HTML and formatted print output. In a Linux distribution, this package is typically needed by documentation toolchains, build systems, and users who publish DocBook-based manuals or project documentation.

The package is mainly relevant to:

• documentation maintainers who build DocBook sources into published output,
• developers who generate HTML or print-ready documentation from XML,
• build and CI/CD systems that validate documentation builds,
• distribution maintainers who ship DocBook publishing tooling.

Purpose and typical use cases

The stylesheets solve a practical publishing problem: they convert structured DocBook source into presentation formats without requiring every project to write its own transformation layer.

Typical uses include:

• generating HTML documentation from DocBook XML,
• producing print-oriented output through the DocBook toolchain,
• building package documentation during RPM or distro package builds,
• testing documentation sources in CI before release.

If a packaging workflow depends on DocBook output, this package is often part of the documentation build path rather than a runtime application dependency.

Upstream project

Upstream is the DocBook XSLT 1.0 stylesheets project maintained in the DocBook ecosystem. The project documentation describes these stylesheets as the long-standing XSLT 1.0 DocBook publishing toolchain, and the upstream repository is the canonical source for the code mirrored here.

Useful upstream references:

• the project repository,
• the DocBook stylesheets overview,
• the generated reference documentation for parameters, processing instructions, and templates.

Dist-git repository contents

This NiceOS dist-git repository contains packaging metadata, not the full upstream source tree.

Typical layout:

• SPECS/ — RPM spec files and packaging logic,
• SOURCES/ — source metadata and manifest files used to describe upstream content,
• METADATA/ — repository metadata used by the packaging workflow,
• SBOM/ — software bill of materials data when maintained for the package.

Large upstream source archives are intentionally not stored in this Git repository. That keeps the dist-git repository small and reviewable while still allowing maintainers to reconstruct the expected source set from the tracked metadata.

Source storage and integrity policy

Source integrity is tracked through the manifest files stored in SOURCES/. Those manifests record what the package expects to fetch or verify, without embedding mutable build state into the repository.

For maintainers, this means:

• verify that the manifest entries still match the upstream source set,
• confirm that any regenerated source metadata is updated together with the spec file,
• avoid relying on locally cached artifacts that are not represented in the repository.

Do not expect large upstream archives to appear in Git. They are intentionally excluded from this repository and should be handled through the normal packaging source process.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream changed files that affect the transformation output,
• whether any packaging patches still apply cleanly,
• whether SOURCES/ manifests need regeneration,
• whether SBOM/ data, if present, needs refresh,
• whether the spec file still points at the correct source layout and install paths.

Things to watch for during an update:

• stylesheet behavior changes that may affect generated documentation,
• renamed or removed upstream files,
• changes in generated docs or reference files that the package installs,
• any downstream patches that may need to be rebased or dropped.

If the upstream project changes its build or release layout, NiceOS maintainers should verify the package before publishing the update.

Build and verification checklist

For an RPM update, a maintainer should normally verify the following:

• the spec file parses cleanly,
• source manifests in SOURCES/ match the intended upstream source set,
• any local patches still apply and are still necessary,
• %prep, %build, %install, and file lists work as expected,
• the package builds in a clean mock or comparable isolated environment,
• installed files match the expected documentation or stylesheet layout,
• generated outputs used by downstream packages still render correctly,
• the package passes any repository or policy checks used by NiceOS.

If the package is used by documentation builds in the distribution, it is worth testing at least one representative DocBook conversion after the update.

References

• DocBook stylesheets overview
• DocBook XSLT 1.0 stylesheets repository
• DocBook XSL stylesheets reference documentation
• DocBook documentation portal

Russian documentation

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

Dist-git repository notes

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