dconf

Overview

dconf is a low-level configuration system used in GNOME. In practice, it acts as a storage and access layer for application and desktop settings, and it is commonly used as the backend for GSettings. For administrators, developers, and desktop maintainers, it is the piece that makes structured settings available to GNOME and GNOME-based software without each application inventing its own storage format. (wiki.gnome.org)

Purpose and typical use cases

Typical use cases include:

• storing per-user desktop and application preferences;
• providing system-wide defaults for GNOME settings;
• locking selected keys so users cannot override site policy;
• inspecting or editing settings with tools such as dconf-editor when troubleshooting or developing applications. (wiki.gnome.org)

Typical users include:

• desktop users who need their own settings preserved between sessions;
• administrators who want to define or control defaults for a managed environment;
• developers who use GSettings-backed configuration in their applications;
• CI/CD or distribution maintainers who need to package and verify the configuration stack as part of a desktop environment. The exact scope of packaging in NiceOS should be verified against the repository metadata and spec file. (help.gnome.org)

Upstream project

Upstream documents dconf as a GNOME project and a main configuration utility in GNOME. The project page describes it as a low-level configuration system with support for change notification, multiple configuration sources, and policy-controlled writes. NiceOS maintainers should treat that page and the upstream administrative documentation as the primary references when checking package updates. (wiki.gnome.org)

Dist-git repository contents

This NiceOS RPM dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to track the upstream sources that belong with the package;
• METADATA/ — package metadata used by the dist-git workflow;
• SBOM/ — software bill of materials material, when present for the package.

The exact file set may vary by packaging policy, but the repository is intended to contain packaging metadata rather than full upstream source payloads.

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/.

For maintainers, this means the important checks are:

• confirm that the spec file still points to the intended upstream source;
• confirm that the SOURCES/ manifest matches the source payload expected by the build system;
• confirm that any generated metadata or auxiliary files still reflect the upstream release being packaged;
• verify that no packaging-only file was accidentally changed during the update.

Do not rely on repository history alone to establish source integrity. Use the manifests and the build system’s verification workflow.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• whether upstream changed build requirements or optional components relevant to the spec file;
• whether any generated files in SPECS/ or SOURCES/ need to be refreshed;
• whether the packaging still matches the upstream documentation and installation model;
• whether the source manifests in SOURCES/ still describe the exact source material expected by the build;
• whether changes affect desktop behavior, system defaults, or lock-down behavior that may matter in managed environments.

If the package carries generated metadata, maintainer patches, or SBOM material, those files may also need regeneration or review. If it is not obvious from the diff what must be refreshed, verify it before relying on the update.

Risks to consider:

• configuration packages can affect desktop login behavior and application defaults;
• a small upstream change may alter package split assumptions or file installation paths;
• policy-related settings may affect user experience in managed environments;
• packaging drift can happen if generated files are not updated together with the spec.

Build and verification checklist

For RPM maintainers, a practical update check is:

1. Review the upstream release notes or change log.
2. Compare the spec file against the new upstream build inputs.
3. Confirm that SOURCES/ contains the correct manifest entries for the intended source payload.
4. Inspect METADATA/ and SBOM/ for files that may need refreshing.
5. Build the SRPM and binary RPMs in a clean environment.
6. Run the package’s standard test or sanity checks if they exist in the build recipe.
7. Verify installed files, ownership, and any configuration paths expected by downstream tooling.
8. If the package influences system defaults, validate a test user session or a throwaway VM.
9. Check that documentation or packaging notes still describe the package correctly.
10. Rebuild after any patch refresh to ensure the repository is internally consistent.

References

• GNOME dconf project page
• Manage user and system settings with dconf
• Profiles
• Control system settings with keyfiles
• Lock down specific settings

Russian documentation

See README_RU.md for the Russian documentation.

Dist-git repository notes

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