doxygen

Overview

Doxygen is a documentation generator for source code. It reads annotated source files and configuration files, then produces documentation in formats such as HTML, man pages, LaTeX/PDF, XML, and others depending on the build and configuration. In practice, it helps turn inline comments and project structure into browsable reference documentation for software projects. (doxygen.nl)

In a Linux distribution, the package exists so maintainers and users can install a standard tool for generating API and developer documentation from source trees. This is especially useful when a project already uses Doxygen-style comments or ships a Doxyfile-based documentation workflow. (doxygen.nl)

Purpose and typical use cases

Typical use cases include:

• generating project API reference documentation from source comments;
• publishing HTML documentation for developers and integrators;
• producing man pages or XML output for downstream tooling;
• keeping documentation generation reproducible as part of a build or CI job;
• documenting libraries and applications that already use Doxygen markup.

Typical users include:

• developers maintaining source documentation;
• release engineers and CI/CD maintainers who generate docs in pipelines;
• distribution packagers who need the tool available in the build environment;
• documentation and technical writing teams that consume generated output;
• administrators who build or package software from source.

Upstream project

The upstream project is Doxygen, an open source documentation generator maintained as a cross-platform tool. The official project site provides the user manual, download page, installation notes, and other reference material. NiceOS maintainers should verify any packaging-specific assumptions against the current upstream documentation before updating the package. (doxygen.nl)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source-side metadata and manifest files used by the packaging workflow;
• METADATA/ — repository metadata used by the forge and package tooling;
• SBOM/ — software bill of materials artifacts, when present.

The repository is intended to contain packaging metadata, not full upstream source trees.

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/ and related packaging metadata. This keeps the repository small and makes updates easier to review.

When updating the package, NiceOS maintainers should verify that the manifests and any source references still match the expected upstream release artifacts. Do not rely on assumptions carried over from a previous update if upstream packaging details have changed. If the upstream layout or distribution method changes, the maintainer should check whether the manifest or spec logic needs to be refreshed.

NiceOS maintenance notes

Before updating this package, check at least the following:

• whether the upstream release still uses the same build and install workflow;
• whether the spec file needs adjustments for new build requirements or changed file paths;
• whether any generated packaging files need regeneration, including manifests under SOURCES/ and any SBOM content;
• whether the update affects documentation output, installed paths, or script behavior used by downstream consumers;
• whether upstream documentation changed in a way that affects packaging assumptions.

Risks to consider:

• documentation generators often change supported output behavior, default options, or build dependencies over time;
• generated files may need refresh even when the package logic itself does not change;
• new upstream releases may alter documentation paths or build steps, which can break automated packaging.

If any of these points is uncertain, NiceOS maintainers should verify it before relying on the update.

Build and verification checklist

For RPM maintenance, use a checklist like this:

• confirm the upstream source reference in SOURCES/ is the intended one;
• review the spec for build dependencies, file lists, and any patch set;
• rebuild the SRPM and RPMs in a clean environment;
• check that the package installs the expected binaries, documentation, and metadata;
• run the package test or smoke-test workflow, if one exists in the repository or build system;
• verify that generated documentation-related files still behave as expected;
• inspect the build logs for new warnings or failures;
• confirm that no unintended files are added to the payload.

If the package ships generated documentation or helper data, verify that those outputs are still produced correctly after the update.

References

• Doxygen homepage
• Doxygen download page
• Doxygen manual
• Doxygen installation notes
• Doxygen getting started guide
• Doxygen usage reference

Russian documentation

See README_RU.md.

Dist-git repository notes

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