pkg
pkg copied to clipboard
pkg search may perform "pkg update", but silently
A friend of mine complained that sometimes pkg search
when run under superuser takes very long time to start (~30 seconds). Subsequent runs are normal (fast). I suspect that this noticeable delay could be caused by pkg(8)
updating its package databases which happens without any console output. I didn't debug it deeply enough, but casual observation suggests this explanation, for example, today I did:
# pkg search -U lziprecover (fast, no results because new port & stale catalogue)
# pkg search lziprecover (nothing happens for a while, then new package found!)
lziprecover-1.21 Recovery tool for Lzip compressed data files
# pkg search lziprecover (also fast because all repositories are up to date now)
I'd suggest that pkg(8)
should always perform the update with logging (like the normal pkg update
) so our users won't be confused.
pkg search does perform updates but not silently, it first checks (silently) if there are newer version of the metadata to perform an update, if there is it does perform the update (verbosely) if not it does the search.
OK, so by your explanation, I should have seen the verbose output after second pkg search
(the one without -U
) because before it didn't find the package, and then it does. But I didn't see any output, only the noticeable delay. How's so?
I experience this each (after some period of not doing any pkg command) first search run as root
> uname -a
FreeBSD 11.2-RELEASE-p9 #0
> /usr/bin/time -h pkg search -x lziprecover
11.30s real 6.63s user 0.47s sys
> /usr/bin/time -h pkg search -x lziprecover
0.56s real 0.06s user 0.01s sys
Could it be because of this: 86cbfb4?
hum I missed that change. I need to rethink about it, is it worth it and should it be reverted
Hi, I have found this to be an issue for me (pkg 1.15.6, freebsd 12.1) as a fairly newbie user. My local-unbound was broken (as I later found out) and pkg search seemed to hang indefinitely without me knowing that it was trying to connect somewhere.