dnf

Overview

DNF is the RPM package manager used to install, upgrade, remove, and query software on RPM-based systems. Upstream describes this repository as DNF4 and notes that DNF5 has a separate project. For NiceOS, this package exists so the distribution can provide the standard command-line package management tool and the files needed to build and maintain it in the RPM packaging workflow. (github.com)

Purpose and typical use cases

Typical use cases include:

• managing system packages from configured repositories
• resolving dependencies during installation and upgrades
• updating metadata and synchronizing repository state
• scripting package operations in automation, provisioning, or CI jobs
• supporting distribution maintenance workflows that depend on RPM transactions

Typical users are:

• system administrators
• developers working on RPM-based distributions
• CI/CD maintainers and release engineers
• security and compliance teams that need repeatable package state
• desktop and server users who manage software from the command line

Upstream project

Upstream project: rpm-software-management/dnf

Upstream currently describes DNF as a package manager based on libdnf and libsolv that replaces YUM. The project repository also contains build and test instructions, source layout, and package documentation. NiceOS maintainers should verify upstream notes before relying on any behavior that may vary by branch or major release line. (github.com)

Dist-git repository contents

This dist-git repository is the packaging source of record for NiceOS. It normally contains:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source control metadata and manifests used to track upstream inputs
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials material, when present for the package workflow

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/ and the packaging metadata around them.

Source storage and integrity policy

The repository should stay small and reviewable. Do not commit large upstream archives here unless the packaging policy explicitly requires a different arrangement.

What to check:

• that the manifest entries in SOURCES/ match the intended upstream input
• that any regenerated packaging metadata is updated together with the spec changes
• that the source set matches the expected upstream release or snapshot
• that no accidental local files, build outputs, or cache files were added

If any part of the source selection or integrity metadata is unclear, NiceOS maintainers should verify it before using the package in a release.

NiceOS maintenance notes

Before updating the package, check:

• whether the upstream project changed its packaging expectations, build system, or test layout
• whether SPECS/ needs a patch refresh, changelog update, or dependency adjustment
• whether files under SOURCES/ need regeneration because the upstream source set changed
• whether SBOM/ or other metadata should be refreshed to reflect the new source inputs
• whether the update changes CLI behavior, repository handling, plugin interaction, or test assumptions
• whether the branch policy for niceos-5.2 requires backport review or extra compatibility checks

Keep an eye on risks common to package manager updates:

• repository metadata handling changes
• dependency solver behavior changes
• scriptlet or transaction behavior differences
• packaging layout drift between upstream branches
• changes that affect automation, image builds, or repository-based provisioning

If a change affects user-visible behavior, document it in the spec changelog or companion packaging notes, not in a version-pinned README.

Build and verification checklist

For RPM maintainers, a practical check list is:

1. Review the upstream change and confirm it belongs to the DNF branch packaged here.
2. Check SPECS/ for patch carry, macro changes, dependency edits, and build-system updates.
3. Confirm SOURCES/ manifests still describe the intended upstream inputs.
4. Regenerate any packaging metadata that depends on the new source set.
5. Build the SRPM and binary RPMs in a clean mock or equivalent build root.
6. Run the package test suite if the spec exposes one and if the build environment supports it.
7. Inspect the resulting RPM payload for unexpected file additions or removals.
8. Verify command-line startup, basic repository operations, and package transaction paths in a test environment.
9. Check that any SBOM or ancillary metadata remains consistent with the packaged source set.
10. Review the final spec diff for accidental version-specific text that would age quickly.

References

• Upstream project repository
• Upstream releases

Russian documentation

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

Dist-git repository notes

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