autogen

Overview

AutoGen is GNU software for generating program text from templates and definitions. In practice, it is used when a project needs to keep repeated text in sync across multiple files, such as generated source fragments, option-processing code, and related documentation. The upstream manual describes it as a tool for repetitive text generation and notes its AutoOpts add-on for option handling and documentation. (gnu.org)

In a Linux distribution, this package is typically useful as a build-time code generation tool and as a dependency for projects that use AutoGen templates, AutoOpts, or generated documentation. NiceOS maintainers should verify the exact role of the package in each consumer before changing packaging assumptions.

Purpose and typical use cases

Typical use cases include:

• generating boilerplate or repetitive source text from a single definition file;
• keeping option parsing code, usage text, and manuals synchronized;
• regenerating generated files during package builds or upstream release preparation;
• supporting projects that already ship AutoGen definitions or AutoOpts-based option handling. (gnu.org)

Typical users include:

• RPM and distribution maintainers who need a reproducible build-time generator;
• developers who work on projects that use AutoGen templates or AutoOpts;
• release engineers and CI/CD maintainers who rebuild generated artifacts;
• documentation maintainers when generated manuals or option text must stay consistent.

Upstream project

Upstream is the GNU AutoGen project. Its official home page and manual describe it as "The Automated Program Generator" and document the main tool, the generated documentation, and the AutoOpts add-on. (gnu.org)

Canonical upstream references are listed below. If the packaging needs deeper upstream detail, NiceOS maintainers should prefer the GNU manual and official project pages over third-party summaries. (gnu.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec file(s) and packaging logic;
• SOURCES/ — source metadata and manifest files used to record what upstream sources are expected;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when present in the package workflow.

Large upstream source archives are intentionally not stored in this Git repository. Only the packaging metadata needed to identify and verify sources is kept here.

Source storage and integrity policy

Source integrity is tracked through manifest files in SOURCES/, not by keeping the full upstream archive in Git. This keeps the repository small and avoids duplicating large vendor tarballs.

Before updating the package, NiceOS maintainers should confirm that the manifest still matches the intended upstream source set and that any new upstream files are expected. Do not rely on repository contents alone if the upstream release process changes.

NiceOS maintenance notes

Before updating this package, check the following:

• whether upstream changed the generator output format, command-line behavior, or documented build requirements;
• whether any files in SOURCES/ need to be regenerated or replaced to match the new upstream source set;
• whether the spec file still applies cleanly and whether build-time patches remain necessary;
• whether regenerated files in dependent packages need to be refreshed after the update;
• whether packaging still matches the repository layout and source manifest policy;
• whether any downstream consumers depend on behavior that is only implicitly documented upstream.

Risks to consider:

• generated output may change even when the upstream feature set appears unchanged;
• downstream packages may fail if they expect a specific generated file layout or option text;
• spec or patch drift can cause rebuild failures that are not obvious from the upstream changelog alone.

If a detail is uncertain, NiceOS maintainers should verify it against the upstream release notes and the relevant generated artifacts before relying on it.

Build and verification checklist

For RPM maintenance, a practical checklist is:

1. Verify that the sources referenced by SOURCES/ are the intended upstream inputs.
2. Check the spec file for stale patches, path changes, or obsolete build steps.
3. Rebuild the package in a clean environment.
4. Confirm that the build completes without unexpected regeneration failures.
5. Inspect the resulting RPM metadata and installed files for the expected layout.
6. If the package ships generated documentation or helper output, compare it with prior builds for unintended changes.
7. Run any package-specific smoke tests or upstream self-checks that are available.
8. Confirm that dependent packages still build or run correctly if they consume generated output from AutoGen.

References

• GNU AutoGen home page
• GNU AutoGen manual
• GNU AutoGen manual, HTML
• AutoGen and AutoOpts documentation

Russian documentation

See README_RU.md for the Russian version.

Dist-git repository notes

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