adwaita-icon-theme-legacy

Overview

adwaita-icon-theme-legacy packages the legacy Adwaita icon artwork used by GNOME applications and other desktop software that rely on named icon themes. In a Linux distribution, this kind of package exists so applications can continue to find the expected icons through the standard icon-theme lookup paths instead of bundling their own copies.

The package is mainly relevant where an application or desktop component expects the Adwaita icon theme or a compatible legacy icon set to be available. NiceOS maintainers should verify the exact icon directories and installed theme metadata when updating the package, because icon-theme layouts can change upstream.

Purpose and typical use cases

Typical use cases include:

• providing the legacy Adwaita icon assets used by desktop applications;
• keeping icon lookups working for software that names icons through the standard GTK/icon-theme mechanism;
• serving as a distribution package for desktop environments, application stacks, and image builders that need the theme files installed in the filesystem.

Typical users are:

• desktop users who rely on applications using the Adwaita icon theme;
• system administrators and image builders who want a consistent desktop icon theme in managed systems;
• CI/CD and release maintainers who validate that the packaged files still install and resolve correctly;
• distro packagers and GNOME stack maintainers who need to keep theme metadata in sync with upstream.

Upstream project

The upstream project is hosted in the GNOME GitLab namespace. It is part of the GNOME icon-theme ecosystem, which provides standard named icons for desktop applications. GTK and GNOME documentation describe icon themes as the mechanism applications use to resolve icon names to themed artwork. (developer-gnome-org-components-8f7ddc.pages.gitlab.gnome.org)

Upstream repository:

• GNOME / adwaita-icon-theme-legacy

If the upstream repository layout or build system changes, NiceOS maintainers should verify the current packaging assumptions before updating this RPM.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and package metadata used for building the SRPM and binary RPMs;
• SOURCES/ — source manifest files and other source-control metadata used to describe what should be fetched for the build;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material associated with the package, if present in this repository layout.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source integrity information in SOURCES/ manifests so the build system can fetch and verify the expected source inputs.

Source storage and integrity policy

For this package, the source policy is straightforward:

• upstream source archives are kept outside the Git history;
• SOURCES/ contains the manifest information needed to identify the expected source inputs;
• the spec file and source manifests should agree on what is fetched during a build;
• maintainers should treat source-manifest updates as part of the packaging change, not as an incidental detail.

Do not rely on the repository alone as a complete source mirror. If a source fetch fails, or if an upstream tarball layout changes, the manifest and spec file should be checked together.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check the following:

• whether the upstream project still installs the same icon theme layout and metadata names;
• whether any files in SOURCES/ need to be regenerated or refreshed;
• whether the spec file needs path, file list, or build-step updates;
• whether SBOM/ content needs to be updated to match the package inputs;
• whether the update affects desktop integration expectations for GNOME or other GTK-based applications.

Main risks to consider:

• icon lookup regressions if upstream renames directories or theme metadata;
• packaging drift if the installed file list changes without a corresponding spec update;
• accidental omission of files required by desktop applications;
• build failures caused by changes in upstream build tooling or generated files.

NiceOS maintainers should verify any upstream changes before assuming the package remains compatible with previous packaging logic.

Build and verification checklist

For RPM maintenance work, use a checklist similar to the following:

• confirm that the spec file still points to the expected upstream source inputs;
• review SOURCES/ for stale or regenerated manifest data;
• check that the %files list matches the installed icon theme files;
• build the SRPM and binary RPMs in a clean environment;
• inspect the build logs for missing files, path mismatches, or unexpected generated content;
• install the resulting RPM into a test root or container and confirm the icon theme files land in the expected directories;
• verify that a sample GTK application or icon-theme lookup can see the installed icons, if that is part of the package’s intended role;
• review SBOM/ if your packaging policy requires it;
• compare the resulting package contents against the previous build for unexpected removals or additions.

References

• GNOME / adwaita-icon-theme-legacy
• GNOME Components: adwaita-icon-theme
• GTK IconTheme documentation
• GTK themed icon guidance

Russian documentation

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

Dist-git repository notes

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