Solved pkg upgrade, >0 candidates, Your packages are up to date.

L

lht

What does this situation mean? Is something broken when this happens?
How do I find out what these candidates are, and why they supposedly don't need to be upgraded?
 
What makes you think anything should be updated in the first place?

Also: what is the exact command you used? Because that could also be of influence.
 
pkg upgrade.

And normally when there have been upgrade candidates, it has proceeded to upgrade them. But now in my case there are 12 candidates and it doesn't wish to upgrade them. And I haven't been able to find out what the identities of these candidates are, whether something is screwed up somewhere or whether it makes sense that these are not to be upgraded...

I keep thinking there must be some sort of verbosity knob somewhere.
 
Post the whole command and the exact error (or lack thereof).
 
# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking for upgrades (12 candidates): 100%
Processing candidates (12 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
 
Possibly, but how do I verify this? The idea that it might just keep saying "12 candidates" for months is very strange when that hasn’t been my experience of using the pkg tools.

If it would just tell me the candidates, I could check that I have the latest versions, for instance. (I'm on latest, not quarterly)
 
Make sure you're not confusing the outputs of pkg version -vI and pkg version -vR.

The first compares against a local /usr/ports/INDEX-*, the latter compares against the remote repository.

Code: 
     The database of available packages and versions to compare against the
     installed packages may be chosen by specifying one of -P, -R or -I or by
     by setting VERSION_SOURCE in pkg.conf(5).  If not specified then the
     ports index file will be used if it exists (-I).  Otherwise, should a
     ports tree exist that will be used to compare versions (-P).  Failing
     either of those two choices, the repository catalogue will be used (-R).
See pkg-version(8).
 
I actually hadn't been looking at pkg version at all.

Last night I finally discovered that global options in pkg(8) are not mentioned in pkg-upgrade(8), where I thought it would be self-contained. So there's --debug, which gave a little more info, such as "solver: for package: xcb-util-xrm cannot find provide for requirement: libxcb.so.1", and then I found that pkg.conf has a DEBUG_LEVEL that I could set to greater values. At 2, I get interesting messages like "cannot find variable dependency xcb-util-image" and "cannot find variable dependency perl5", etc.

It looks like you're probably right that I have the latest versions of the relevant packages despite whatever's unhappy, and that's a relief.

I'm still going to try to dig into what's going on, and if I figure anything out, I'll mention it here for others who have similar issues in the future... I hope it's not some sort of database corruption, as I am not eager to learn sql.
 
Try forcing an update of the remote repository database. It sometimes gets out of sync and you can get some weird results because of it.

pkg update -f
 
Ah. I didn't try that, but I did find yesterday that, for all x in "solver: for package: x cannot find provide for requirement: y", "pkg upgrade -f x" removed them from the candidates list.

I see that when a thread is finished, it will tend to have a green Solved. How is that added?
 
lht said:
I see that when a thread is finished, it will tend to have a green Solved. How is that added?
Click to expand...
Just edit the first post of the thread (topic starter). The label is right next to the subject.
 
You must log in or register to reply here.
Back
Top