Here, reinstalling everything, even with a lightweight desktop, is out of the
question, too many ports installed.
The pkg_* utilities were fine for what they were... IMHO. The pkg(ng) utility appears as good, maybe better, howsoever as I've been posting here and
in the freebsd-ports list, there are at least some users who view it as a much
more capable (in most ways) portupgrade+and+pkg_* replacement, and view its intended
(by a majority of those, probably, who are currently testing/deploying it) "default"
status as not necessary, as it (now) removes the flat files in /var/db/pkg (each directory a registration database of the port, so to speak) and
replaces that information (useful by portmaster, portupgrade, portmanager, one's
custom scripts, find/grep pipes, shell-aided file browsing...) with a front-end
for which as yet only a few equivalents (the more common ones?) exist, concurrently
precluding an even-better portmaster, portupgrade... [ remaining issues omitted,
straying too far from the topic of the thread. ]
/edit/
I posted a use case I found later today after this post to the
freebsd-ports list, where using a port that views/selects text
files and the shell for tab-completion I can find in about five
seconds flat the number and names of other ports already installed that the
dependency that I may/may not have installed, depend upon it, whereas using
pkg query, not only choosing the particular port to check from
ports installed would take probably longer than that 5 seconds,
but then, the pkg query command syntax to view what is already
onscreen with the file viewer, shell, and command line, is not
yet in the EXAMPLES section of the manual, and it it were, would
take at least some parameters to the command to remember, whereas
now, the port that selects the directory in /var/db/pkg, also selects the +REQUIRED_BY with the up/down
arrows, (still at the non-desktop console), and so no switches/syntax
delay to immediately ( five seconds in this case) obtain the information is incurred.
So while pkg may be a great tool, the flat-files in /var/db/pkg are for at least some users, presently very useful
instead. (Inasmuch as that use case, is only one of about ten or
fifteen I use every year, maybe too many to abstract away into
a API interface to the package registration status.)
