Before that change the code would do the following:
1- if dependency is installed, continue
2- if dependency is queued, continue
3- get dependency from repos
After that change the code does this:
1- if dependency is queued, continue
2- if dependency is installed, continue
3- get dependency from repos
So the dependency is checked if it has been queued as the first phase, which
seems to be the most common path in most cases.
In pwwka's case for some reason the transaction was trying to configure
'man-pages-3.62_1' while in pkgdb there was only 'man-pages-3.55_1'.
By using the pkgname the pkg stored in pkgdb will be configured, without
caring what version it is.
- Rather than using a POSIX named semaphore use a POSIX lock (lockf(3))
for pkgdb for writers. Writers that cannot acquire the pkgdb lock will
get EAGAIN rather then being blocked.
- Due to using a file lock we cannot write the pkgdb every time a package
is being unpacked, configured or removed. Instead pkgdb is only written
at the end of a specific point in the transaction (unpack, configure, remove)
or via xbps_pkgdb_unlock().
This function is similiar to xbps_fetch_file(). In contrast to xbps_fetch_file()
xbps_fetch_file_dest has an extra paramenter which allow to define an output file
for the request.
The issue was that xbps_pkgdb_get_pkg() did not find any package,
and the code was free(3)ing heap allocated memory before checking for
errno. I suspect that free(3) has touched errno and this errno value
has been propagated to the next code.
Found after a bit of testing on repo.voidlinux.eu.
The variables to set cachedir, rootdir and metadir have been
changed to "array of chars", this way there are no extra allocations.
Update clients accordingly and bump API version.
The previous internal "struct rpool" was an extra structure that
can be avoided by just using "struct xbps_repo" directly.
This makes rpool use (at least) 4KB less per repository and 1
extra allocation.
