Hi, I'm looking for a second opinion on whether I've run into a bug in pkg(8) regarding local repositories.
I currently build a small handful of packages locally from ports(7) and also manually install them, but I wanted to try using a local pkg repository to handle that instead. On one of my FreeBSD systems, I created a local repo config,
/usr/local/etc/pkg/repos/LOCAL.conf:
I then ran
On that system, for the jail host, my custom built packages get dropped into /jails/mounts/pkgs/${JAILNAME}/. Running pkg-repo(8) on that directory at the jail host level has no issues, and when the jail is started, it will mount that path as /opt/pkgs read-only. For the squid jail, it is currently running squid-6.9, but I created a local port to test an upgrade to squid-6.10 (which compiled successfully), and placed the built package file into the host path that the jail can see as its /opt/pkgs and re-ran
So this has me stumped. I'm wondering if it's a bug in pkg not handling the version increment correctly? E.g., maybe sorting as a string, not an integer, thus it thinks that 6.9 > 6.10, when it should really be the other way around? But I'm also having a hard time thinking such a simple sorting bug would remain undetected for so long, unless the use of a local repository gums up the sorting logic somehow.
It seems that pkg can SEE the 6.10 copy if I run pkg-search(8), but it appears the way it sorts that output suggests it's really looking like a sorting bug, since it's sorting "6.10" before "6.9" (I think the higher version should be on the bottom if it's sorting correctly):
E.g., this is what the aforementioned
The higher version here is on the bottom, so pkg correctly determines that 4.19.7 > 4.19.6_1.
If I evict squid-6.9's package from the
Are there any advanced debugging tricks I can enable to see deeper into what logic pkg is using to decide which version it prefers to install? Or is this enough to go and open a PR against pkg?
I currently build a small handful of packages locally from ports(7) and also manually install them, but I wanted to try using a local pkg repository to handle that instead. On one of my FreeBSD systems, I created a local repo config,
LOCAL, and saved it as /usr/local/etc/pkg/repos/LOCAL.conf:
Code:
# locally-built packages from ports(7)
LOCAL: {
url: "file:///opt/pkgs/",
# signature_type: "fingerprints",
# fingerprints: "/usr/share/keys/pkg",
enabled: yes,
conservative_upgrade: yes,
priority: 1000
}I then ran
pkg repo /opt/pkgs/ to create the repo metadata files. On this particular system, this appeared to work well, as dropping an upgraded net/samba419 package in the directory caused pkg to detect the upgrade. However, when I tried to do the same thing to a jail that runs www/squid on another FreeBSD system...something seems to not be working right.On that system, for the jail host, my custom built packages get dropped into /jails/mounts/pkgs/${JAILNAME}/. Running pkg-repo(8) on that directory at the jail host level has no issues, and when the jail is started, it will mount that path as /opt/pkgs read-only. For the squid jail, it is currently running squid-6.9, but I created a local port to test an upgrade to squid-6.10 (which compiled successfully), and placed the built package file into the host path that the jail can see as its /opt/pkgs and re-ran
pkg repo on the jail host. Inside my squid jail, I ran pkg update -f, then removed the original package that was manually installed (by absolute file path to pkg install) and tried to re-install it using just the package name of squid so that pkg would search the configured repos. The catch here is while pkg sees the squid packages in the LOCAL repository, it is ignoring the recently-built 6.10 version, preferring instead to want to install 6.9:
Code:
# pkg install squid
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating LOCAL repository catalogue...
LOCAL repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
libunwind: 20240221 [FreeBSD]
squid: 6.9 [LOCAL]
Number of packages to be installed: 2
The process will require 86 MiB more space.
206 KiB to be downloaded.
Proceed with this action? [y/N]: nSo this has me stumped. I'm wondering if it's a bug in pkg not handling the version increment correctly? E.g., maybe sorting as a string, not an integer, thus it thinks that 6.9 > 6.10, when it should really be the other way around? But I'm also having a hard time thinking such a simple sorting bug would remain undetected for so long, unless the use of a local repository gums up the sorting logic somehow.
It seems that pkg can SEE the 6.10 copy if I run pkg-search(8), but it appears the way it sorts that output suggests it's really looking like a sorting bug, since it's sorting "6.10" before "6.9" (I think the higher version should be on the bottom if it's sorting correctly):
Code:
# pkg search -r LOCAL squid
squid-6.10 HTTP Caching Proxy
squid-6.9 HTTP Caching ProxyE.g., this is what the aforementioned
pkg search command looks like for the other system w/ the samba419 update:
Code:
# pkg search -r LOCAL samba419
samba419-4.19.6_1 Free SMB/CIFS and AD/DC server and client for Unix
samba419-4.19.7 Free SMB/CIFS and AD/DC server and client for UnixThe higher version here is on the bottom, so pkg correctly determines that 4.19.7 > 4.19.6_1.
If I evict squid-6.9's package from the
LOCAL repo and regen the metadata, THEN pkg will want to install or upgrade to squid-6.10. If I move the 6.9 package back in, regen the metadata again, then it reverts to only wanting to use 6.9 and it ignores 6.10 entirely. So something is definitely screwy here.Are there any advanced debugging tricks I can enable to see deeper into what logic pkg is using to decide which version it prefers to install? Or is this enough to go and open a PR against pkg?
