acpid

Overview

acpid is a user-space ACPI event daemon for Linux. It listens for ACPI-related events and runs configured helper programs when those events occur. In practice, this is how a system can react to actions such as power button presses, lid close events, AC adapter changes, or other ACPI notifications exposed by the kernel. (sourceforge.net)

This package exists in NiceOS to provide that daemon in a distributable, maintainable RPM form. For a Linux distribution, the package is typically part of the base system or of system-management software, but NiceOS maintainers should verify the exact role in the target product and not assume a particular default installation state.

Purpose and typical use cases

Typical uses of acpid include:

• reacting to ACPI power-management events through local scripts or helper commands;
• integrating laptop or workstation hardware events into system policy;
• letting administrators define site-specific handling for ACPI notifications;
• supporting desktop or mobile systems where power-button and lid events need predictable handling.

Typical users are:

• system administrators who want consistent power-event handling;
• desktop and laptop maintainers who need local ACPI policy;
• distribution or image maintainers who package default event handlers;
• CI/CD or automation maintainers who test that the service starts, reads its configuration, and responds to events as expected.

Upstream project

The upstream project is the ACPI daemon project hosted on SourceForge. Its public project page describes acpid as “a configurable ACPI policy daemon for Linux.” The project documentation also notes that the daemon uses kernel ACPI event interfaces and that newer kernels expose event delivery through netlink and the input layer. (sourceforge.net)

NiceOS maintainers should verify upstream packaging details, release notes, and any behavior changes directly against the upstream project pages before updating the RPM.

Dist-git repository contents

This dist-git repository contains the packaging metadata for the RPM, not the full upstream source tree.

Common top-level content:

• SPECS/ — the RPM spec file and related packaging logic;
• SOURCES/ — source manifests and other source-control metadata used by the build system;
• METADATA/ — repository metadata maintained by the packaging workflow;
• SBOM/ — software bill of materials data, when provided by the packaging process.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository keeps source-manifest information under SOURCES/ so the build system can verify what should be fetched and built.

Source storage and integrity policy

Source integrity is tracked through the manifest files in SOURCES/. Those manifests record which upstream source artifacts belong to the package without embedding changing build-time state in the README.

For maintainers, this means:

• verify that the manifest entries still match the intended upstream source;
• confirm that any refreshed source set is complete;
• check that the packaging metadata still references the correct source material;
• avoid assuming that a manifest-only update is automatically safe without review.

NiceOS maintainers should also verify whether the package requires regeneration of auxiliary metadata such as patches, generated helper files, or SBOM content.

NiceOS maintenance notes

Before updating this package, check the following:

• upstream release notes for behavior changes relevant to ACPI event handling;
• whether any spec file patches still apply cleanly;
• whether the service unit, configuration defaults, or helper scripts need updates;
• whether documentation or man-page expectations changed upstream;
• whether repository metadata in METADATA/ or SBOM/ needs regeneration;
• whether the source manifests in SOURCES/ still point to the correct upstream material.

Risks to consider:

• changes in event delivery paths, such as kernel interface adjustments;
• changed defaults in helper scripts or configuration files;
• accidental removal or renaming of packaged handlers;
• build failures caused by outdated patches or tooling assumptions.

If any of these details are uncertain, NiceOS maintainers should verify them before relying on the update.

Build and verification checklist

A practical RPM-maintainer checklist for this package:

• review the upstream release notes and compare them with the current packaging;
• verify that the SOURCES/ manifests still match the intended upstream source;
• inspect the spec file for outdated patches or file lists;
• rebuild the RPM in a clean mock or equivalent isolated build environment;
• confirm that build-time dependencies are still correct;
• run package checks such as %check, linting, and file-ownership validation if they are available in the packaging workflow;
• install the built RPM in a test environment;
• confirm that the daemon starts cleanly and reads its configuration;
• validate that packaged helper scripts or rules are installed where expected;
• if applicable, test a representative ACPI event path on real or suitably emulated hardware;
• review the resulting SBOM and metadata files if they are part of the repository workflow.

References

• ACPI daemon Project (acpid) on SourceForge
• acpid project site
• acpid2 branch on SourceForge

Russian documentation

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

Dist-git repository notes

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