The latest version of libstdc++ in Arch Linux at this point (13.1.1)
pulls in the following code via `#iterator <iterator>` when
`-std=gnu++2b` is used:
```
template<forward_iterator _It>
struct __basic_const_iterator_iter_cat<_It>
{ using iterator_category =
iterator_traits<_It>::iterator_category; };
```
The latest version of Clang in Arch Linux at this point (15.0.7)
complains about a missing `typename` here. To avoid this error
from preventing the build, this changes enables error resilience
for the reflection generation to turn this error into a warning.
* Avoid aborted build actions from being stuck in running state while
waiting until the chroot locks can be acquired; allow aborting action
immediately instead
* Use async locks when invoking makechrootpkg and split affected function
accordingly
This might be useful to avoid blocking threads in the thread pool just for
waiting on a global lock. It might also be useful to allow stopping build
actions while they're waiting for a lock.
The `packageName` (key in build preparation) might not actually be
`pkgbase` when rebuilding a binary package and `pkgbase` changes compared
to what it was in the before. Then `packageName` is still set to the old
`pkgbase` and we need to use the name from the actual source info (which is
the name `pkgbase` value).
Skip package as expected when a dependency failed that was attempted to be
built as last package of the previous batch (and building as far as
possible is enabled).
When adding a new database when reloading the config at runtime the
architecture must be passed when creating the database. Otherwise we end up
with the new database sharing the internal storage with the x86_64 database
which leads to very confusing behavior.
* Avoid using buildDate of PackageInfo in favor of the same field in
PackageBase
* PackageInfo::buildDate should be removed on the next breaking change
* Do not really use the deprecated attribute because it is still used by
(de)serialization code until it is removed for good
* Break backwards compatibility
* Allow to deserialize only base-data of packages and build
actions to potentially speed up showing tables
* Speed up package search in many cases by only deserializing
base-data (unless details are actually wanted)
* Avoid creation of map with all archive contents; instead parse packages
while walking though the archive
* Avoid instantiation of std::string in come cases (using std::string_view)
* Reuse libarchive's archive entry when walking though archive
* Use visitor-based database parser in all places to avoid intermediate big
array with all package objects
Especially when enabling files DBs it is quite problematic to store all
package objects of a database within one big array. This change avoids the
array and instead adds the packages directly. The disadvantage is that
clearing the database isn't as simple anymore.
* Avoid keeping list of all packages in memory by pushing each package
directly to the JSON array
* Avoid check for database before pushing each package; do it only before
reaching the next database
* Remove no longer required functions
* 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
Martchus