Those are a wrapper around xbps_{array,dictionary}_internalize_from_zfile()
that prints a debugging msg when the plist file cannot be internalized.
Update xbps to use these wrappers.
- 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().
In some tasks the single threaded implementation outperms the multithreaded
one. Use it where it really makes a difference. The _multi() routines do not
spawn any thread if _SC_NPROCESSORS_ONLN == 1.
Bump XBPS_API_VERSION.
This routine will spawn a thread per core to process N items stored
in the specified array, the last thread gets the remainder of items left.
Results have shown that xbps benefits if there is a considerable amount
of items and number of threads being spawned.
Use it in xbps_pkgdb_foreach_cb(), xbps-pkgdb(8), xbps-query(8)
and xbps-rindex(8).
On UP systems there's no overhead because pthread(3) is not used at all.
WIP! investigate if it can be used in libxbps (xbps_rpool_foreach()),
and finish conversion of xbps-rindex(8) -c.
The list of required external deps is now confuse, libarchive and openssl.
libxbps now includes a wrapper for proplib prefixed with xbps_ rather than prop_.
These are the core interfaces in the new API:
rpool - Interface to interact with the repository pool.
rindex - Interface to interact with repository indexes.
pkgdb - Interface to interact with local packages.
transaction - Interface to interact with a transaction.
This also brings new repository index format, making the index file
per architecture and being incompatible with previous versions.
The transaction frequency flush option has been removed, and due to
the nature of package states it was causing more harm than good.
More changes coming soon, but the API shall remain stable from now on.
