pkg upgrade # What is "(1 candidates)"? [reproducible]

  • Thread starter Thread starter Deleted member 65380
  • Start date Start date
Doesn't provide much clues where it's coming from:
Code: 
root@fbsd-test:~ # pkg -d upgrade
DBG(1)[24465]> pkg initialized
Updating FreeBSD repository catalogue...
DBG(1)[24465]> PkgRepo: verifying update for FreeBSD
DBG(1)[24465]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
DBG(1)[24465]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/meta.conf
DBG(1)[24465]> opening libfetch fetcher
DBG(1)[24465]> Fetch > libfetch: connecting
DBG(1)[24465]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/meta.conf with opts "i"
DBG(1)[24465]> Request to fetch pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/quarterly/packagesite.txz
DBG(1)[24465]> opening libfetch fetcher
DBG(1)[24465]> Fetch > libfetch: connecting
DBG(1)[24465]> Fetch: fetching from: http://pkgmir.geo.freebsd.org/FreeBSD:13:amd64/quarterly/packagesite.txz with opts "i"
FreeBSD repository is up to date.
All repositories are up to date.
DBG(1)[24465]> want to get an advisory lock on a database
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
DBG(1)[24465]> problem has no requests
Checking integrity...DBG(1)[24465]> check integrity for 0 items added
 done (0 conflicting)
Your packages are up to date.
DBG(1)[24465]> release an advisory lock on a database
 
Just to point out it seems independant of what is installed, the candidates number was 1 despite 6 packages or 1 package - from my earlier scenarios. Also independent of architechture (aarch64 vs amd64) or FreeBSD release (13 vs 12.2), pkg upgrade exhibits the same behaviour (on an affected/fresh install).
 
Last edited by a moderator:
tux2bsd said:
Just to point out it seems independant of what is installed, from my earlier scenarios the candidates number was 1 despite 6 packages or 1 package. Also independent of architechture (amd64 vs ASDF) or FreeBSD release 13 vs 12.2, same behaviour.
Click to expand...
For info:
To day i make the last PC migrate, FreeBSD 12.2 to 13.0
After the last reboot and pkg update && pkg upgrade....
Code: 
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
 
No, but I've honestly haven't had the time to look through the sources yet.
 
Maybe this can help your investigation:

I played a bit with DragonFly (a FreeBSD fork that also uses pkg) and noticed that after switching the pkg repository to a mirror closer to me, pkg upgrade would suddenly mention a big number of such "candidates" although there was nothing new to upgrade.

This made me understand that pkg considers as a candidate anything that was installed from another repository than what is currently enabled. On FreeBSD, this can typically be locally built packages. I tried unlocking my locked packages and they would still show up as "candidates", so what is relevant is the fact I built them from ports, not the fact they are locked. Maybe it can also be the case of packages which were installed from pkg but are currently not in the repository anymore.

In your case, this may be... pkg itself.
Try pkg upgrade -f pkg
 
Ah. Subtle. So I started off with pkg(8) being the only thing that was installed:
Code: 
root@fbsd-test:~ # pkg version -vR
Updating FreeBSD repository catalogue...
Fetching packagesite.txz: 100%    6 MiB   2.2MB/s    00:03
Processing entries: 100%
FreeBSD repository update completed. 30362 packages processed.
All repositories are up to date.
pkg-1.16.3                         =   up-to-date with remote
Then pkg upgrade showed that 1 candidate:
Code: 
root@fbsd-test:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): 100%
Processing candidates (1 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
But pkg(8) doesn't have any dependencies, so where does this candidate come from? And as it's the only package that's installed there's nothing that would pull in any other implicit dependencies, and thus there should be 0 candidates.

So I did a forced reinstall:
Code: 
root@fbsd-test:~ # pkg install -f pkg
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
        pkg-1.16.3 [FreeBSD]

Number of packages to be reinstalled: 1

8 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching pkg-1.16.3.txz: 100%    8 MiB   2.9MB/s    00:03
Checking integrity... done (0 conflicting)
[1/1] Reinstalling pkg-1.16.3...
[1/1] Extracting pkg-1.16.3: 100%

And now the candidates is gone:
Code: 
root@fbsd-test:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.

So what I think might happen here is that the pkg(7) bootstrap causes pkg itself to be registered as an implicit dependency, thus 1 candidate. But it's already installed so nothing needs to be done. By doing a re-install using the "proper" pkg(8) tool this implicit dependency was removed and consequently also removed that 1 candidate.
 
SirDice said:
So I did a forced reinstall:
Code: 
root@fbsd-test:~ # pkg install -f pkg
Click to expand...
Good thinking to try that.
SirDice said:
So what I think might happen here is that the pkg(7) bootstrap causes pkg itself to be registered as an implicit dependency, thus 1 candidate. But it's already installed so nothing needs to be done. By doing a re-install using the "proper" pkg(8) tool this implicit dependency was removed and consequently also removed that 1 candidate.
Click to expand...
Makes total sense as an explanation of the undesirable behavior.
 
SirDice can you please submit a bug report so that coders can find and fix the bug.
 
bsduck said:
Do it yourself instead of asking others to.
Click to expand...

I don't know the official process to post a bug report for FreeBSD. Does my Forum login let me do that?

I noticed this bug and ultimately demonstrated to it to a FreeBSD staff member, surely that would go somewhere?
 
tux2bsd said:
I don't know the official process to post a bug report for FreeBSD.
Click to expand...

FreeBSD Bugzilla Main Page

bugs.freebsd.org bugs.freebsd.org

tux2bsd said:
Does my Forum login let me do that?
Click to expand...
No, you need to register an account with the bugtracker. Anyone can sign up and report bugs.

tux2bsd said:
I noticed this bug and ultimately demonstrated to it to a FreeBSD staff member, surely that would go somewhere?
Click to expand...
I'm not a FreeBSD staff member, I'm a user just like you (ok, I do have 20 years more experience than you but you get the idea). I'm an admin on this forum, that's all. The 'Staff member' label refers to my status on the forums, moderators and admins are staff members. Registered FreeBSD developers will have an @ after their name.
 
Thanks for the links.

SirDice said:
The 'Staff member' label refers to my status on the forums, moderators and admins are staff members. Registered FreeBSD developers will have an @ after their name.
Click to expand...
That's not stupidly misleading and confusing at all... (this is not directed at you personally)
p.s. normal forum plebs see this from your link:

Oops! We ran into some problems.​

You do not have permission to view this page or perform this action.
Click to expand...
 
SirDice said:
So what I think might happen here is that the pkg(7) bootstrap causes pkg itself to be registered as an implicit dependency, thus 1 candidate. But it's already installed so nothing needs to be done. By doing a re-install using the "proper" pkg(8) tool this implicit dependency was removed and consequently also removed that 1 candidate.
Click to expand...
I think you should add that to the bug report. Another person concurring with additional information will help.
SirDice said:
ok, I do have 20 years more experience than you with FreeBSD but you get the idea
Click to expand...
You should stop patting yourself on the back... I also added a correction in bold.
 
It might not be the correct interpretation. I've set up a new server at work, and because I had to do this "offline" before I racked it, I installed all required packages using pkg-add(8). It's now racked and running. Looking at pkg upgrade it has 83 packages installed and shows 83 candidates with everything up to date (it has to be up to date because I copied the same repository to a USB stick to install it locally). So it looks like it has something to do with the difference between pkg-add(8) and pkg-install(8). The pkg bootstrap also uses pkg-add(8) to install itself.

So the candidate also indicates packages that have been installed locally. Compared to a remote repository they're a candidate to upgrade, but because it's already installed and the correct version there's nothing getting updated (it would be a pointless reinstall). If I just run pkg upgrade -f to reinstall everything from the remote repository then the candidates return to 0.
 
tux2bsd said:
Interesting but so gross.
Click to expand...
Not really, it's explainable, pkg(8) keeps track of where packages come from. It's correctly determining those packages are candidates to upgrade, but because they're up to date with the remote repository there's no need to upgrade them.
 
Being explainable doesn't stop something being gross. Let's not forget it wasn't long ago this wasn't explainable:
SirDice said:
It's certainly not common knowledge, maybe it has something to do with
Click to expand...
At the bare minimum searching the pkg-upgrade man page for 'candidate' should have a bit more explaination. Maybe SirDice could give the pkg people some words for their man page?

If it is a bug, like I think it is, it could be fixed.
 
VladiBG said:
Use debug opt.
Click to expand...

SirDice said:
… the candidate also indicates packages that have been installed locally. …
Click to expand...

I wonder about three of these four candidates:

Code: 
% pkg -d upgrade -r poudriere -n
DBG(1)[74170]> pkg initialized
Checking for upgrades (4 candidates): 100%
Processing candidates (4 candidates): 100%
DBG(1)[74170]> Binary> loading //usr/local/poudriere/data/packages/main-default/All/meson-0.60.2.pkg
Checking integrity...DBG(1)[74170]> check integrity for 1 items added
 done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        meson: 0.60.1_1 -> 0.60.2 [poudriere]

Number of packages to be upgraded: 1
% pkg query -a '%o %v %R' | grep unknown | sort
emulators/virtualbox-ose-kmod 6.1.30 unknown-repository
graphics/drm-current-kmod 5.4.144.g20211012 unknown-repository
graphics/drm-kmod g20190710_1 unknown-repository
graphics/gpu-firmware-kmod g20210330 unknown-repository
net/citrix_ica 13.10.0 unknown-repository
sysutils/beadm 1.3.2 unknown-repository
www/waterfox 2019.12.c unknown-repository
x11-fonts/fontconfig 2.13.94_1,1 unknown-repository
x11-toolkits/linux-c7-openmotif 2.3.4_6 unknown-repository
% pkg query -e '%a = 0' '%o %v %R' | grep poudriere | sort
deskutils/recoll 1.31.2 poudriere
editors/linux-wps-office 11.1.0.10161 poudriere
emulators/virtualbox-ose 6.1.30 poudriere
net/td-system-tools 1.2.0 poudriere
ports-mgmt/pkg 1.17.5 poudriere
ports-mgmt/poudriere-devel 3.3.99.20211017_2 FreeBSD
science/linux-zotero 5.0.96.3 poudriere
sysutils/brut 1.55 poudriere
sysutils/cpufetch 1.00 poudriere
sysutils/lsblk 3.7 poudriere
x11-themes/kde-icons-black-and-white 2.0.a poudriere
% pkg query -e '%a = 1' '%o %v %R' | grep poudriere | sort
audio/festlex-oald 1.4.1_1 poudriere
audio/linux-c7-flac 1.3.0_2 poudriere
audio/linux-c7-gsm 1.0.13 poudriere
audio/linux-c7-libogg 1.3.0_1 poudriere
audio/linux-c7-libsndfile 1.0.25_6 poudriere
audio/linux-c7-libvorbis 1.3.3_2 poudriere
audio/linux-c7-pulseaudio-libs 10.0_3 poudriere
devel/binutils 2.37_2,1 poudriere
devel/linux-c7-dbus-glib 0.100_1 poudriere
devel/pcre2 10.39 poudriere
devel/py-six 1.16.0 poudriere
dns/linux-c7-libasyncns 0.8_1 poudriere
ftp/curl 7.80.0 poudriere
graphics/wayland-protocols 1.23 poudriere
lang/vala 0.48.18,1 poudriere
math/fftw3 3.3.9_1 poudriere
multimedia/dav1d 0.9.2 poudriere
multimedia/libdca 0.0.7 poudriere
net/linux-c7-tcp_wrappers-libs 7.6_2 poudriere
textproc/docbook-xml 5.0_3 poudriere
textproc/expat2 2.4.1 poudriere
x11-fonts/libXfont2 2.0.5 poudriere
x11/libX11 1.7.2,1 poudriere
x11/libxshmfence 1.3_1 poudriere
%

In my case, most unknown-repository listings are for packages that resulted from a make installkernel routine.

I wondered about version changes that might not require an upgrade. Ploughed through the lists of non-automatic and automatic packages from my poudriere repository, found no discrepancy. For example, devel/binutils 2.37_2,1 above and:

Code: 
% pkg rquery '%o %v %R' binutils
devel/binutils 2.37_2,1 FreeBSD
devel/binutils 2.37_2,1 poudriere
%

Some of these should help to understand how the number of candidates is calculated:
  • {link removed} (2014-05-28)
  • {link removed} (2014-06-06)
  • {link removed} (2014-08-06)
  • {link removed}
 
Last edited:
You must log in or register to reply here.
Back
Top