automake

Overview

Automake is the GNU tool that helps generate Makefile.in files from project templates. It is used with GNU Autoconf and is intended to reduce the amount of handwritten Makefile maintenance needed in projects that follow GNU build conventions. In a Linux distribution, the package is primarily useful to developers and maintainers who need to regenerate build system files during packaging, backporting, or upstream source preparation. (gnu.org)

Purpose and typical use cases

Typical use cases include:

• generating distribution-ready build metadata from Makefile.am templates;
• preparing upstream source trees for packaging in RPM-based distributions;
• regenerating build system files after patches to configure.ac, Makefile.am, or related autotools inputs;
• checking whether a source tree follows the conventions expected by GNU build tooling. (gnu.org)

Typical users are:

• package maintainers and distribution engineers;
• upstream developers who use Autoconf and Automake;
• CI/CD maintainers who need reproducible build-system regeneration in pipelines;
• release engineers preparing source tarballs or buildable trees.

Upstream project

The upstream project is GNU Automake, part of the GNU build toolchain. The upstream project states that it generates Makefile.in files compliant with the GNU Coding Standards and that it requires GNU Autoconf. The canonical upstream project site is the GNU Automake page, and the manual is published by the GNU Project. (gnu.org)

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging metadata;
• SOURCES/ — source integrity manifests and related metadata used by the packaging workflow;
• METADATA/ — repository metadata maintained by the packaging system;
• SBOM/ — software bill of materials artifacts when present.

The repository stores packaging inputs and metadata, not the full upstream source archive. That keeps the Git history manageable and avoids storing large upstream tarballs in the dist-git repository.

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 still points to the expected upstream source content;
• verify that any regenerated source metadata matches the packaging policy used in NiceOS;
• do not assume that the repository contains the full upstream source tree;
• treat any change in upstream source location or packaging layout as something that must be reviewed before updating the package.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream release changes any autotools behavior that affects generated build files;
• whether configure.ac, Makefile.am, or other autotools inputs in dependent packages need regeneration;
• whether the spec file still matches the build requirements used by the distribution;
• whether any repository metadata in METADATA/, SOURCES/, or SBOM/ needs regeneration or review;
• whether the update changes the expected behavior of build-time tools used by dependent packages.

Practical risks to consider:

• regenerating build files can alter generated output in dependent packages;
• packaging updates may affect bootstrap or rebuild workflows;
• changes in upstream conventions can require coordinated updates in multiple packages.

If any of these points are unclear for a specific update, NiceOS maintainers should verify them before relying on the package.

Build and verification checklist

For RPM maintainers, a typical update checklist is:

1. Confirm that the upstream source referenced by the manifests is the intended one.
2. Review the spec file for packaging changes needed by the new upstream release.
3. Check whether repository metadata or SBOM artifacts need to be refreshed.
4. Rebuild the SRPM and RPMs in the target build environment.
5. Verify that generated build-system files still behave as expected in dependent packages.
6. Run the package test and install workflows used by NiceOS, if available.
7. Review build logs for autotools-related warnings, missing files, or path issues.
8. Confirm that no unintended changes were introduced into source integrity metadata.

References

• GNU Automake
• GNU Automake Manual
• GNU Coding Standards

Russian documentation

For the Russian version of this document, see README_RU.md.

Dist-git repository notes

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