Marc,
What was the rational to put "./" as the first search path in the default
PKG_PATH, in particular? And include "./" in there at all, in general?
* * *
Yesterday on Libera Chat we debugged a related problem followed by a
conversation about pkg_add, pkg_info, and default PKG_PATH.
I've learned more and I'd like to provide more insight now.
Jan Stary, 2024-12-11 14:03 +0100:
> For the record, 'pkg_info -v -Q tcl' emits the list below for me.
Jan,
I believe you run -current, hence you get a different (longer) list than me.
(I run -stable, yes; mentioned at the end of my original email.)
Here's why:
Default PKG_PATH is "./:installpath". The "installpath" then expands to
include "/%c/packages/%a/" and the "%c" expands:
- On -current: to "snapshots".
- On -stable: to "%v", a release version;
- Furthermore, the "packages" part is replaced with "packages-stable"
(provided no "-D snap" option is given).
The "packages-stable" directory has fewer, newer packages. It masks the
directory "packages", which is full of -release packages. So "-a" must
be added to "pkg_info -aQ pkg-name" in order to search an entire
packages catalogue.
To emulate on -stable that behaviour you observe on -current,
run "pkg_info -D snap -Q pkg-name".
See also:
- src:usr.sbin/pkg_add/OpenBSD/State.pm
- src:usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm
- pkg_add(1)
> > I couldn't find what is a repository (in the context of the pkg_info(1)
> > man page), nor how they might be set up. I assume it's related to
> > installurl(5) and PKG_PATH env. var.
The word "repository" refers to ":"-separated entries in PKG_PATH.
Man pages pkg_add(1) and pkg_info(1) inconsistently refer to these
entries as repositories, paths, and directories.
Contents of installurl(5) is used to expand the special PKG_PATH entry
"installpath".
* * *
A short version of a long story on Libera Chat is this.
"pkg_add -un" from cron reported updates, but "pkg_add -u"
from shell didn't install any updates. Later: "pkg_add -u"
would or would not install updates basing on CWD. It turned out
there was an old package tarball on disk that prevented updates.
The reason for that long user's confusion is that default PKG_PATH
includes "./" as the first search path. "pkg_add -u" would see a package
in CWD, figure out it's older than the installed version, and bail.
Although the behaviour is explicitly documented, it's very confusing
that, with a user's intention to update all system packages,
the observed behaviour of "pkg_add -u" changes basing merely
on presence or absence of package-ly named files in a current working
directory.
This extends to pkg_info too, e.g.:
# touch tcl-0.deadbeef.tgz
# pkg_info -Q tcl
tcl-0.deadbeef
