color-filesystem

Overview

color-filesystem is a packaging of filesystem layout and color-related directory conventions used on Unix-like systems. In practice, packages in this area usually provide the directory structure and policy needed by other software that installs color metadata, terminal color definitions, or related shared data under standard locations such as /usr/share. The exact upstream scope for this package should be verified by NiceOS maintainers against the source package contents and spec file before relying on it.

In a Linux distribution, a package like this usually exists to make sure the expected directories and metadata layout are present in a consistent form so that dependent packages can install files without embedding their own filesystem-policy assumptions.

Purpose and typical use cases

Typical use cases include:

• providing a standard place for color-related shared data;
• making filesystem layout expectations explicit for other packages;
• helping package builds and install scripts place files in distribution-approved locations;
• serving as a reference point for maintainers who need to check where color or filesystem-policy files belong.

Typical users are:

• distribution maintainers and RPM packagers;
• system administrators who inspect installed filesystem layout packages;
• developers packaging tools that install shared data into standard directories;
• CI/CD maintainers validating package installation and file placement.

Upstream project

The upstream subject of this package should be treated as filesystem-layout documentation and policy rather than a conventional application. The Filesystem Hierarchy Standard documents the expected layout of shared data under /usr, including /usr/share/color as color-management information. The dir_colors(5) manual page documents dircolors configuration and the LS_COLORS mechanism used by ls(1). These references are the safest starting point for understanding what the package is intended to support. (specifications.freedesktop.org)

If NiceOS maintainers find additional upstream files or project pages in the source package, they should verify whether they are authoritative for this package and update this section accordingly.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec file(s) for building the package;
• SOURCES/ — source metadata and manifest files used to describe the upstream source set;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, if present for this package.

The large upstream source archives themselves are intentionally not stored in this Git repository. Instead, the repository keeps the metadata needed to identify and verify the source content.

Source storage and integrity policy

NiceOS tracks source integrity through manifest files in SOURCES/. The manifest data is used to describe which upstream artifacts belong to the package without keeping the full archive history in Git.

Maintainers should avoid treating the repository contents as the complete upstream source tree. Before updating the package, verify that the manifest still matches the intended upstream source set and that any regenerated metadata is committed together with the spec changes.

NiceOS maintenance notes

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

• confirm the upstream scope still matches the package name and summary;
• verify whether the update changes any installed paths under /usr/share or similar shared locations;
• review SPECS/ for packaging logic that may need changes because of new or removed files;
• regenerate SOURCES/ manifests if the upstream source set changes;
• update SBOM/ material if the project or packaging workflow requires it;
• check whether the package still conforms to distribution filesystem policy and whether any files should move to a different package;
• look for accidental additions of generated files, local patches, or build outputs that should not be versioned.

Risks to consider during update review:

• file layout changes that can break dependent packages;
• packaging drift if the spec starts assuming a different upstream structure;
• stale metadata in SOURCES/ or SBOM/ after upstream changes;
• ambiguity about whether a directory or policy file belongs here or in another package.

Build and verification checklist

For RPM maintainers, a practical update checklist is:

• inspect the spec file diff before merging;
• verify the source manifest in SOURCES/ reflects the intended upstream input;
• confirm the package installs only the expected filesystem-policy or layout files;
• build the SRPM and RPM locally in a clean environment;
• check the installed file list for unexpected paths or ownership issues;
• review %files entries for completeness and no accidental omissions;
• run any available packaging tests or install checks;
• confirm SBOM/ contents, if present, still match the packaged source set;
• verify that no generated build artifacts were committed back into dist-git.

References

• Filesystem Hierarchy Standard
• /usr/share: Architecture-independent data
• dir_colors(5) manual page

Russian documentation

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

Dist-git repository notes

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