vasilito
1b8fd21eba
The verify-overlay-integrity.sh script is now active. It runs at the start of canonical builds and auto-repairs via apply-patches.sh on failure. Restored missing symlinks for: - recipes/core/base/redox.patch - recipes/core/bootloader/redox.patch - recipes/core/bootloader/P2-live-preload-guard.patch - recipes/core/bootloader/P3-uefi-live-image-safe-read.patch - recipes/wip/wayland/qt6-wayland-smoke (incorrect relative path) Created empty stub at local/patches/base/redox.patch so the relibc/base symlinks can be re-created by apply-patches.sh. Overlay integrity now reports: 365 recipe symlinks, 0 broken 9 patch symlinks, 0 broken 9 critical patches, 0 missing 10 critical configs, 0 missing
GVDB
GVDB (GVariant Database) is a simple database file format that stores a mapping from strings to GVariant values in a way that is extremely efficient for lookups.
The code is intended to be pulled into projects as a submodule/subproject, and it is not shipped as a separately compiled library. It has no API guarantees.
A GVDB database table is a single file. It is designed to be memory mapped by one or more clients, with accesses to the stored data being fast. The storage format has low size overheads, assuming the GVariant formats for values do not require much padding or alignment.
Modifying a GVDB table requires writing out the whole file. This is
relatively slow. gvdb_table_write_contents() does this by writing out
the new file and atomically renaming it over the old one. This means
that any clients who have memory mapped the old file will need to reload
their memory mapping.
This means that if multiple clients are using a GVDB table, an external
process is needed to synchronise writes and to notify clients to reload
the table. dconf-service is an example of such a process.