dblatex

Overview

dblatex is a publishing tool for converting DocBook XML or SGML sources into LaTeX, DVI, PostScript, or PDF. It is used when a document workflow starts with DocBook and the final output is expected in one of the LaTeX-driven formats. The upstream documentation describes it as a program that transforms DocBook documents into LaTeX first, then relies on standard LaTeX tools for output generation. (dblatex.sourceforge.net)

In a Linux distribution, this package typically exists so that documentation authors, release engineers, and build systems can render DocBook-based manuals and technical books without carrying a separate ad hoc conversion stack. NiceOS maintainers should verify the exact integration points used in this branch if packaging decisions depend on local documentation workflows.

Purpose and typical use cases

Typical use cases include:

• building project manuals from DocBook source trees;
• generating printable PDF documentation from DocBook books or articles;
• producing DVI or PostScript outputs for legacy publishing workflows;
• running document builds in CI/CD pipelines where DocBook sources need to be turned into distributable artifacts;
• maintaining custom LaTeX formatting for a documentation set when the upstream styling is acceptable or can be adapted locally.

Typical users are:

• documentation maintainers;
• build and release engineers;
• CI/CD maintainers who need repeatable document builds;
• developers who ship technical documentation with their software;
• desktop users who work with DocBook-based content and need a local conversion tool.

Upstream project

Upstream is the dblatex project at the official project site. The project documentation describes dblatex as a DocBook to LaTeX publishing tool, and the manual explains that it can also be used with different LaTeX backends such as pdftex, dvips, and xetex. (dblatex.sourceforge.net)

Upstream documentation also notes that dblatex is intended to hide much of the LaTeX build machinery behind a single conversion script. That is useful for maintainers because it reduces the amount of custom glue needed around a DocBook publishing pipeline. (dblatex.sourceforge.net)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and package metadata used for building the package;
• SOURCES/ — source control metadata and manifest files that describe the upstream inputs used by the build;
• METADATA/ — repository metadata maintained by the packaging workflow;
• SBOM/ — software bill of materials material associated with the package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. NiceOS maintainers should use those manifests as the packaging reference point and verify that the fetched upstream inputs still match the intended source set before publishing updates.

Source storage and integrity policy

The repository keeps small, reviewable metadata in Git and leaves large upstream archives out of tree. This keeps the dist-git repository lightweight and avoids committing bulky vendor payloads.

What to check before trusting an update:

• confirm that the upstream source set is the one expected for this package;
• confirm that any SOURCES/ manifest entries still point to the correct upstream artifacts;
• confirm that no unintended files were added or removed from the source set;
• confirm that any local downstream patches still apply cleanly.

If the upstream project changes its release layout or packaging style, NiceOS maintainers should verify whether the existing source manifests still describe the correct inputs.

NiceOS maintenance notes

Before updating this package, maintainers should check:

• whether upstream behavior or command-line options changed in a way that affects packaging or documentation builds;
• whether the spec file still reflects the required runtime and build-time tools for the targeted NiceOS branch;
• whether any downstream patches are still needed, can be dropped, or must be refreshed;
• whether the source manifests in SOURCES/ need regeneration because the upstream source set changed;
• whether the SBOM material, if present for this package, needs to be refreshed to match the updated source or packaging metadata;
• whether the update changes document rendering in a way that affects test output, file paths, or installed examples.

Risks to consider:

• document build failures caused by upstream template or style changes;
• unexpected differences in generated output files;
• local patch drift;
• changes in upstream release layout that make the manifest set incomplete or stale;
• packaging regressions caused by missing or renamed helper scripts.

Build and verification checklist

A practical RPM maintainer checklist:

• review the spec file for obsolete patches or stale build requirements;
• verify that the SOURCES/ manifest set matches the upstream inputs intended for the build;
• rebuild the package in a clean environment;
• run the package test or smoke-test path used by NiceOS for this repository, if available;
• confirm that the installed files match the expected layout;
• confirm that documentation generation still works for at least one representative DocBook input, if the package or its tests cover that workflow;
• inspect build logs for warnings that indicate missing tools, broken paths, or incompatible upstream changes;
• compare the resulting artifacts with the previous package only for functional differences, not for mutable build metadata.

References

• dblatex project home
• dblatex manual: convert DocBook to LaTeX, DVI, PostScript, and PDF
• dblatex manual: publishing principles
• dblatex manual: introduction

Russian documentation

See README_RU.md.

Dist-git repository notes

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