cpuinfo

Overview

cpuinfo is a library for detecting information about the host CPU. In practice, it helps software identify processor capabilities, topology, cache layout, and related CPU characteristics at runtime.

In a Linux distribution, this package is usually present to support software that needs CPU detection without embedding its own platform-specific code. The library is typically useful to applications that make runtime decisions based on the local processor.

Purpose and typical use cases

Typical use cases include:

• choosing optimized code paths at runtime
• checking whether a target CPU exposes specific instruction sets
• discovering cache and topology information for scheduling or tuning
• inspecting processor details in tools that report hardware characteristics
• supporting portable software that needs the same CPU-detection logic across platforms

Typical users include:

• application developers who need runtime CPU feature detection
• system administrators and performance engineers who inspect CPU characteristics
• CI/CD and build maintainers who verify that CPU-dependent code behaves correctly on different machines
• distribution maintainers who package software that depends on host CPU information

Upstream project

Upstream: pytorch/cpuinfo

The upstream project describes cpuinfo as a CPU information library. NiceOS maintainers should verify any upstream changes that affect supported architectures, build options, or platform-specific detection logic before updating the package.

Dist-git repository contents

This dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source metadata and manifest files used to track upstream sources
• METADATA/ — repository metadata used by tooling and package management workflows
• SBOM/ — software bill of materials material, if maintained for this package

The repository contains packaging metadata and source-tracking information, not a full copy of every upstream release artifact.

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/. Maintainers should treat those manifests as the authoritative packaging record for the imported source tree and verify that any new upstream import matches the expected source set.

When updating the package, NiceOS maintainers should confirm that:

• the imported source set still matches the upstream project layout
• the source manifests were regenerated or updated correctly
• any packaging patches still apply cleanly
• no unintended local files were added or removed

If the source layout changes upstream, maintainers should verify whether the manifest files, spec file references, or auxiliary packaging metadata also need updates.

NiceOS maintenance notes

Before updating this package, check the following:

• verify the upstream project state and whether the change is a source refresh, a packaging-only change, or both
• review the spec file for build-system changes, patch ordering, and any file list updates
• confirm whether SOURCES/ manifests need regeneration after source import changes
• check whether SBOM/ or other compliance material needs to be refreshed
• review architecture-specific code paths if upstream changed CPU detection logic
• watch for behavior changes in runtime detection, especially where fallback logic or platform probing is involved
• confirm that any local patches still make sense with the current upstream codebase

Risks to consider:

• upstream changes may alter CPU feature detection on some architectures
• source layout changes may require packaging adjustments
• platform-specific fixes may need revalidation on non-x86 systems
• build failures can appear if the package depends on generated files or external build tooling that changed upstream

If a detail is uncertain, NiceOS maintainers should verify it before relying on it.

Build and verification checklist

For RPM maintenance, a practical checklist is:

• inspect the spec file for current build requirements and file ownership rules
• verify that the source manifest in SOURCES/ matches the imported upstream source set
• rebuild the package in a clean mock or comparable build environment
• check that all expected subpackages and installed files are produced
• run the package test suite if one is enabled in the build process
• review build logs for warnings that could indicate architecture-specific issues
• confirm that licensing information in the spec and source metadata remains correct
• verify that any patch series still applies and does not carry obsolete workaround code
• if upstream changed public headers or ABI-relevant behavior, confirm dependent packages are not affected

References

• Upstream project on GitHub

Russian documentation

• README_RU.md

Dist-git repository notes

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