As per https://www.sqlite.org/wal.html#read_only_databases:
> Even though it is possible to open a read-only WAL-mode database, it is good
> practice to converted to [PRAGMA
> journal_mode=DELETE](https://www.sqlite.org/pragma.html#pragma_journal_mode)
> prior to burning an SQLite database
> The existence of .sqlite-shm is required for read-only WAL mode to work at
> all (a very important use-case being queries by regular users), see
> https://www.sqlite.org/wal.html#read_only_database
I find this weird - because unprivileged code can't write directly to the
database, what
> It'd be nicer of course if rpm had a supported procedure to "park" databases
> for this kind of thing. --rebuilddb with some special flag maybe.
`--rebuilddb` is much heavier than just a single SQL command. Perhaps
`--parkdb`, along with a corresponding C API function?
--
Reply to this
rpmdb reproducibility is also an issue when building (EL9) containers, it would
be nice to have a park option indeed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2219#issuecomment-1291407794
You are receiving this because you are
Hmm. Actually doing the WAL docs suggested `PRAGMA journal_mode=DELETE` on the
database results in a database that can still be opened by rpm, regular users
and all. Rpm will try to re-establish WAL if opened in read-write mode, so
nothing too terrible should happen if you do the journal delete
The existence of .sqlite-shm is required for read-only WAL mode to work at all
(a very important use-case being queries by regular users), see
https://www.sqlite.org/wal.html#read_only_database
--
Reply to this email directly or view it on GitHub:
This is a followup to
https://github.com/rpm-software-management/rpm/commit/71456f2fc09900a027a33dc3d6d75c69a9b39488
which is about generating bit-for-bit reproducible images (container/disk) that
include an RPM database.
At the time, the person working on that PR was looking at RHEL8 (BDB
