dbus

Overview

D-Bus is a message bus system for inter-process communication. It lets applications and services on the same machine exchange messages through a common bus instead of managing every connection directly. The upstream project also provides the system and session bus daemons and the supporting libraries and tools used by applications, desktop components, and system services. (freedesktop.org)

In a Linux distribution, this package is usually part of the base messaging and service coordination layer. It is needed by software that talks to the system bus or the per-user session bus, and by packages that rely on D-Bus for service activation, notification, or desktop/session integration. NiceOS maintainers should verify the exact dependency role in the distribution before making packaging changes. (freedesktop.org)

Purpose and typical use cases

Typical uses of D-Bus include:

• communication between desktop applications and session services
• communication between system services and components that need to report or request state changes
• message routing through the system bus or the user session bus
• direct peer-to-peer communication through the D-Bus protocol when appropriate
• launching or coordinating services on demand through bus-mediated activation, where supported by the surrounding configuration (freedesktop.org)

Typical users of this package include:

• distribution and platform maintainers who need the core bus daemon and libraries
• desktop engineers who integrate applications with the session bus
• system administrators who troubleshoot service communication on the system bus
• developers who build applications or bindings on top of the D-Bus API
• CI/CD maintainers who verify that dependent packages still build and run against the packaged interfaces (dbus.freedesktop.org)

Upstream project

The upstream project documents D-Bus as a simple way for applications to talk to one another. The public documentation covers the specification, tutorial, FAQ, daemon manual pages, and API reference. NiceOS maintainers should treat the upstream documentation as the primary reference for behavior and interface expectations. (freedesktop.org)

Dist-git repository contents

This dist-git repository contains the packaging sources needed to build the NiceOS RPM package:

• SPECS/ — RPM spec files and packaging logic
• SOURCES/ — source metadata and manifest files used to track upstream inputs
• METADATA/ — repository metadata used by the packaging workflow
• SBOM/ — software bill of materials material, when maintained for this package

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files under SOURCES/. That keeps the repository practical to clone and review while still preserving the packaging-side record of what sources are expected. (freedesktop.org)

Source storage and integrity policy

For this package, the authoritative source-tracking record lives in the SOURCES/ manifests. Maintainers should use those manifests to confirm which upstream inputs are expected for the build. Do not rely on the repository itself as a place to store large tarballs or other bulky upstream artifacts.

When updating the package, NiceOS maintainers should verify that:

• the upstream source set still matches the SOURCES/ manifest entries
• any packaging patches still apply cleanly to the new upstream code
• the spec file still reflects the current upstream layout and build system behavior
• any generated packaging metadata is refreshed if the upstream release changes installed paths, file lists, or build outputs

If a packaging workflow depends on additional manifest or SBOM regeneration, maintainers should confirm those files are updated together so the repository remains internally consistent. If that process is unclear for a given branch, NiceOS maintainers should verify it before relying on it.

NiceOS maintenance notes

Before updating this package, check the following:

• review upstream release notes, changelogs, and documentation for behavior changes that may affect packaging or runtime assumptions
• verify whether patches still apply or need refresh
• inspect the spec file for build-system changes, dependency changes, or file ownership changes
• confirm that SOURCES/ manifests and any related metadata still describe the intended source set
• check whether SBOM/ or other generated repository artifacts need regeneration
• review any installed service units, configuration files, or helper scripts for changed paths or semantics
• assess whether the update changes interaction with desktop sessions, system services, or bus activation behavior

Main risks to consider:

• runtime changes in the bus daemon or libraries that affect dependent packages
• packaging drift when upstream reorganizes files or build outputs
• patch carry changes after upstream refactoring
• accidental mismatch between the manifest files and the actual intended source inputs

If a detail is uncertain, NiceOS maintainers should verify it against upstream documentation or the packaging workflow before depending on it.

Build and verification checklist

Use a maintainer checklist like this before committing a package update:

1. Confirm the upstream source and documentation relevant to the change.
2. Refresh or drop patches as needed.
3. Update the spec file if the build system, install paths, or package split changed.
4. Regenerate any packaging metadata that is derived from the build or source set.
5. Verify the SOURCES/ manifest entries match the intended inputs.
6. Run a local build in a clean environment.
7. Check that the resulting RPM contents match expectations.
8. Validate dependency resolution for packages that consume D-Bus.
9. If applicable, run basic runtime checks for the daemon, session bus, or system bus integration.
10. Review the diff for accidental inclusion of generated or machine-specific files.

Useful verification points for RPM maintainers:

• successful source and binary build
• no unexpected file ownership changes
• no unreviewed changes to installed configuration or service definitions
• no stale packaging metadata after the update
• no mismatch between spec logic and the SOURCES/ manifests

References

• D-Bus home page
• D-Bus Specification
• D-Bus Tutorial
• D-Bus FAQ
• dbus-send manual page
• dbus-daemon manual page
• D-Bus API reference

Russian documentation

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

Dist-git repository notes

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