Only implemented where it makes sense to, i.e., not cmpver, pkgmatch, arch, getsystemdir, digest, and fetch.
Tests show a large speed-up is possible when processing a large number of inputs (1718 in this case):
Before
xbps-query -Rp pkgver -s python 0.18s user 0.02s system 99% cpu 0.199 total
cut -d: -f1 0.00s user 0.00s system 0% cpu 0.198 total
xargs -n1 xbps-uhelper getpkgname > /dev/null 0.49s user 1.17s system 94% cpu 1.761 total
After
xbps-query -Rp pkgver -s python 0.17s user 0.03s system 99% cpu 0.200 total
cut -d: -f1 0.00s user 0.00s system 0% cpu 0.200 total
xargs ./bin/xbps-uhelper/xbps-uhelper getpkgname > /dev/null 0.00s user 0.00s system 1% cpu 0.197 total
(note the lack of -n1 in the second one)
add getname and getversion actions
These actions are kind of "meta" actions, combining getpkgdepname and getpkgname (and the respective version actions) so that a list of mixed pkgvers and package patterns can be interpreted. This uses the internal format check of xbps_pkgpattern_{name,version}() to allow for a fallback to xbps_pkg_{name,version}() for exact versions, then falls back to displaying an error message if that also fails.
this will also be somewhat intertwined with an xbps-uhelper manpage, like in #533
Only implemented where it makes sense to, i.e., not
cmpver
,pkgmatch
,arch
,getsystemdir
,digest
, andfetch
.Tests show a large speed-up is possible when processing a large number of inputs (1718 in this case):
Before
After
(note the lack of
-n1
in the second one)These actions are kind of "meta" actions, combining getpkgdepname and getpkgname (and the respective version actions) so that a list of mixed pkgvers and package patterns can be interpreted. This uses the internal format check of
xbps_pkgpattern_{name,version}()
to allow for a fallback toxbps_pkg_{name,version}()
for exact versions, then falls back to displaying an error message if that also fails.this will also be somewhat intertwined with an
xbps-uhelper
manpage, like in #533