* Only lock the config for writing the reloading the config file
* Make sure all write operations to the database acquire an "update mutex"
to ensure only one write operation happens at a time
* Do *not* acquire any additional locks when reading from a database as it
should be safe to do so even when a write operation happens because
* LMDB read and write transactions can happen at the same time
* The package cache has its own mutex anyways
* Write ops to the package cache try to lock the "update mutex" to
prevent writing "old" data to the cache during updates
* Make "lastUpdate" atomic to avoid locking the config when accessing it
* Do HTTP head request first when loading database from mirror to avoid
downloading the full database all the time
* Use the last modification date of the local database file because with
the persistent storage even local database reloads became a bit expensive
Otherwise all other attempts to acquire named locks are blocked. It should
be ok because references are not invalidated when inserting/accessing
elements of an `std::unique_map`. When cleaning locks up elements are
erased, though. Hence an additional cleanup lock is required to prevent
acquiring a named lock which has already been cleaned up.
Simply adding `--sign` to the `makepkg` flags doesn't work because it would
require setting up GPG within the chroot environment (of `makechrootpkg`).
When debugging it is anyways annoying that `makepkg` sends the `gpg` output
to `/dev/null`. This way the logs are preserved.
Martchus