acpica-tools

Overview

acpica-tools packages the ACPICA user-space tools used to inspect, compile, disassemble, and debug ACPI tables. ACPICA is Intel’s open-source implementation of the ACPI specification, and these tools are the practical command-line utilities that go with that code base. They are commonly used when working on firmware, platform bring-up, power-management debugging, or ACPI table validation. (intel.com)

In a Linux distribution, this package exists to make the ACPICA toolchain available in a packaged, reproducible form rather than requiring maintainers or users to build it directly from the upstream tree. For NiceOS, it is especially useful in development, diagnostics, and validation workflows that involve ACPI/AML/ASL artifacts. (intel.com)

Purpose and typical use cases

Typical use cases include:

• compiling ACPI Source Language (ASL) into AML
• disassembling AML back into a readable form
• dumping and extracting ACPI tables for analysis
• exercising ACPI table behavior in a controlled environment
• reviewing firmware- or platform-specific ACPI issues during bring-up and maintenance (intel.com)

Typical users are:

• firmware and platform engineers
• Linux distribution maintainers
• system administrators working on hardware debugging
• developers investigating ACPI-related boot or power-management behavior
• CI/CD or validation maintainers who need repeatable ACPI tooling in test pipelines (intel.com)

Upstream project

The upstream ACPICA project is maintained by Intel and described as an open-source, operating-system-independent implementation of ACPI. Intel’s documentation and download pages are the most reliable references for the project’s purpose, documentation, and source distribution model. The upstream project also notes that the Git tree is a working tree and that releases are the preferred source of stable code for consumers. NiceOS maintainers should verify the exact upstream packaging and release source used for any update. (intel.com)

Dist-git repository contents

This dist-git repository is organized as a standard RPM packaging repository:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source manifest files and related source metadata
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials artifacts, when present

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository tracks source integrity through manifest files in SOURCES/. That keeps the Git history smaller and makes source handling compatible with standard RPM dist-git workflows. (intel.com)

Source storage and integrity policy

The source policy for this package is to keep the large upstream archive outside of Git and record the source references in SOURCES/ manifest files. Maintainers should treat those manifests as the canonical link between the spec file and the imported source material.

Before relying on an update, verify that:

• the manifest still points to the intended upstream source
• the imported source set matches the spec expectations
• no packaging-only file was accidentally changed during import
• any regenerated metadata is consistent with the new upstream source state

Do not rely on the repository alone as proof that the upstream source is correct; check the source manifest and the upstream release or documentation page as part of review. (intel.com)

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether the upstream source used for the update is the intended release or working-tree snapshot
• whether any spec file adjustments are needed for changed build behavior, installed paths, or tool names
• whether SOURCES/ manifests need to be regenerated or refreshed
• whether SBOM/ artifacts, if tracked in this repository, need to be updated to match the new source import
• whether upstream documentation changed in a way that affects packaging or user-facing guidance
• whether the update introduces build-system changes that require local patches or macro updates

Risks to consider:

• ACPI tooling changes may affect output format or parser behavior, which can impact downstream tests or scripts
• upstream source refreshes can invalidate packaging assumptions even when the package name is unchanged
• imported metadata may need review after upstream reorganizes files

If a detail is unclear, NiceOS maintainers should verify it before relying on it. (intel.com)

Build and verification checklist

For RPM maintainers, a practical update checklist is:

1. Review the upstream release notes and documentation for the intended source.
2. Confirm the SOURCES/ manifest matches the source being imported.
3. Check whether the spec file still builds all required tools.
4. Build the RPM in a clean environment.
5. Install the resulting package in a test root or container.
6. Run the package’s basic command-line checks, if available.
7. Verify that the installed file list matches expectations.
8. Confirm that no packaging metadata or SBOM content was left stale.
9. Review any local patches and remove obsolete ones where possible.
10. Re-test any workflows that consume the tools directly, such as ACPI table compilation or disassembly.

If the upstream release notes or build instructions changed, follow those changes rather than assuming the previous update path still applies. (intel.com)

References

• ACPICA overview
• ACPICA documentation
• ACPICA download page
• ACPICA user guide and programmer reference
• ACPICA issue reporting guidance
• ACPICA project repository

Russian documentation

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

Dist-git repository notes

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