at-spi2-core

Overview

at-spi2-core provides the core pieces of the Assistive Technology Service Provider Interface (AT-SPI): protocol definitions, the accessibility registry service, and the client library used by desktop accessibility tools to talk to applications over D-Bus. It is part of the GNOME accessibility infrastructure and is published upstream by the GNOME project. (gnome.pages.gitlab.gnome.org)

For a Linux distribution, this package exists so accessibility consumers and desktop components can share a common interface for inspecting and interacting with accessible applications. NiceOS maintainers should treat it as part of the desktop accessibility stack rather than as an application-specific feature. (gnome.pages.gitlab.gnome.org)

Purpose and typical use cases

Typical use cases include:

• desktop accessibility tools that query UI structure and text content through AT-SPI;
• assistive technologies that need to observe or control application state;
• application and toolkit testing in environments that exercise accessibility paths;
• maintenance of a desktop stack where accessibility behavior must remain consistent across updates. (gnome.pages.gitlab.gnome.org)

Typical users are:

• desktop accessibility engineers;
• distribution maintainers;
• developers working on GNOME or other AT-SPI-aware applications;
• QA and CI/CD maintainers who validate accessibility-related code paths.

Upstream project

Upstream is hosted by GNOME: GNOME at-spi2-core. The project documentation describes AT-SPI interfaces and the development workflow for the accessibility infrastructure. (gnome.pages.gitlab.gnome.org)

The upstream documentation is the main reference for interface behavior and project-specific build or test guidance. If a NiceOS update changes build tooling or test expectations, maintainers should verify the current upstream instructions before relying on older assumptions. (gnome.pages.gitlab.gnome.org)

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 inputs;
• METADATA/ — package metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when present for this package.

The large upstream source archive is intentionally not stored directly in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/, so the repository stays lightweight and reviewable while still recording which upstream material belongs to the package.

Source storage and integrity policy

NiceOS packaging policy for this repository is to keep the Git history focused on packaging metadata, not on copying upstream release archives into the tree. The source manifest in SOURCES/ is the place to check when verifying which upstream inputs are expected for a build.

Before accepting an update, verify that:

• the SOURCES/ manifest matches the intended upstream source set;
• any packaging metadata that refers to generated files is still correct;
• no required file is missing from the source manifest;
• any repository-managed SBOM material still reflects the package contents.

Do not rely on file names or checksums copied from older versions without checking the current manifests.

NiceOS maintenance notes

Before updating the package, NiceOS maintainers should check:

• whether upstream has changed build system requirements or test layout;
• whether the spec file needs refreshed patches, macros, or subpackage handling;
• whether SOURCES/ needs regeneration because upstream source material changed;
• whether any generated packaging artifacts in METADATA/ or SBOM/ need to be updated;
• whether the update affects accessibility behavior, D-Bus interface usage, or daemon/service installation paths.

Risks to consider:

• changes in upstream accessibility interfaces may require packaging review even when the library API looks stable;
• test results can depend on the desktop session and D-Bus environment used during build or validation;
• packaging changes may affect consumers that expect the accessibility registry service to be present or reachable.

If any of these points are unclear for a given update, NiceOS maintainers should verify them in the current upstream documentation and build logs before merging.

Build and verification checklist

Use the following checklist for RPM maintenance work:

• review the spec diff before rebuilding;
• confirm that the source manifest in SOURCES/ matches the intended upstream inputs;
• check whether patches still apply cleanly or need refresh;
• rebuild the SRPM and RPMs in the target NiceOS branch environment;
• run the package test suite if one is enabled upstream or in the spec;
• verify that installed files, libraries, and any service components land in the expected paths;
• check the resulting package metadata for unexpected dependency changes;
• confirm that the accessibility registry or related service files are packaged as intended;
• inspect build logs for warnings that could indicate API, ABI, or toolchain drift;
• if applicable, validate the package in a desktop session or container that can exercise D-Bus and accessibility use cases.

References

• GNOME at-spi2-core
• AT-SPI 2.0 API documentation
• Accessibility infrastructure development guide

Russian documentation

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

Dist-git repository notes

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