attr

Overview

attr provides utilities for working with extended file attributes. In practice, these tools let administrators and developers inspect, set, remove, and script around metadata stored with files, outside the traditional Unix permission bits.

In a Linux distribution, this package is useful when packaging or testing software that stores file metadata, or when maintaining systems that rely on extended attributes for operational workflows. NiceOS maintainers should verify the exact upstream behavior they need before depending on any specific xattr namespace or filesystem interaction.

Purpose and typical use cases

Typical use cases include:

• checking or modifying extended attributes on files and directories;
• scripting metadata handling in system administration tasks;
• validating how software preserves file attributes during copy, backup, archive, or deployment workflows;
• inspecting filesystem metadata during debugging or incident response;
• supporting CI/CD jobs that need to verify attribute handling on test artifacts.

Typical users are:

• system administrators;
• package maintainers;
• developers who need to test filesystem metadata handling;
• CI/CD maintainers;
• security or compliance engineers who need to inspect file metadata behavior.

Upstream project

The upstream project is hosted on Savannah and is described as the attr project for manipulating filesystem extended attributes. The upstream man page for attr(1) describes the tool as a shell-oriented utility for extended attribute manipulation, and points users to getfattr(1) and setfattr(1) for filesystem-independent handling. (man7.org)

For background on extended attributes themselves, the Linux manual pages document xattrs as name/value metadata associated with files, and note that tools such as getfattr and setfattr are used to manipulate them. (man7.org)

Dist-git repository contents

This NiceOS RPM dist-git repository is organized as follows:

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

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, together with the packaging metadata maintained in the repo.

Source storage and integrity policy

The repository keeps packaging metadata and source manifests, not full upstream release archives. This keeps the Git history small and avoids duplicating large vendor tarballs in dist-git.

When updating the package, maintainers should confirm that the manifest data in SOURCES/ matches the intended upstream source set and that any referenced inputs are still valid. Do not rely on stale local copies or unpublished artifacts.

NiceOS maintenance notes

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

• whether upstream changed the behavior of the command-line tools or library interfaces in ways that affect packaging;
• whether the spec file needs refreshes for patches, scriptlets, macros, or dependency declarations;
• whether source manifests in SOURCES/ need regeneration;
• whether SBOM/ or METADATA/ should be updated to match repository policy;
• whether any downstream patch still applies cleanly and remains necessary;
• whether the package still builds on the target NiceOS branch without warnings or test regressions that matter for packaging.

Potential risks to consider:

• upstream changes in filesystem metadata handling may affect behavior on different filesystems;
• attribute handling can vary with kernel and filesystem capabilities;
• packaging changes may alter script or tool paths used by dependent packages;
• if NiceOS carries patches, they may need review for compatibility before rebuilds.

Build and verification checklist

Suggested checklist for RPM maintainers:

• verify the upstream source set expected by SOURCES/;
• review the spec file for obsolete patches or macros;
• rebuild the package in a clean environment;
• check that the generated RPM metadata is consistent with the repository policy;
• run the package tests, if upstream or downstream tests are available and relevant;
• install the built RPM in a test environment and validate the main command-line tools;
• confirm that file attribute operations behave as expected on the intended filesystem types;
• review build logs for warnings that could indicate packaging drift.

References

• Savannah project page
• attr(1) manual page
• attr(5) / xattr(7) manual page

Russian documentation

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

Dist-git repository notes

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