"pkgman up ak.hpkg" misreports "Nothing to do" (whereas "pkgman install" is ok)

[ttcoder]

I noticed what might be a package-kit bug when a dependancy is missing (i.e. absent from both hpkr repos and local files); will leave my system as-is for a few days to reproduce the problem for further diagnosis if needed

Namely, local-file ak.hpkg has a "requires: tts_mimeconfig>=2016.1" dependancy which is not satisfied (there's only an older version, 2015.3, installed)

pkgman install behaves as expected, it says it cannot find the dep:

/boot/system/cache/tmp/tts_updater_temp> pkgman install --home -y armyknife-5.1.
8.0-1-x86_gcc2.hpkg
Downloading repochecksum-1...
Downloading repochecksum-1...done.
Validating checksum for Haiku...done.
Downloading repochecksum-1...
Downloading repochecksum-1...done.
Validating checksum for HaikuPorts...done.
Encountered problems:
problem 1: nothing provides ttscore_mimeconfig>=2016.1 needed by armyknife-5.1.8.0-1
  solution 1:
    - do not install "pkg:armyknife-5.1.8.0-1-x86_gcc2"

but pkgman update does not, it bails out with "nothing to do" message:

/boot/system/cache/tmp/tts_updater_temp> pkgman update --home -y armyknife-5.1.8.0-1-x86_gcc2.hpkg
Downloading repochecksum-1...
Downloading repochecksum-1...done.
Validating checksum for Haiku...done.
Downloading repochecksum-1...
Downloading repochecksum-1...done.
Validating checksum for HaikuPorts...done.
Nothing to do.
/boot/system/cache/tmp/tts_updater_temp> 

I'm setup for compiling this; so dug a little and found that ​fInstalledRepositories.ItemAt(0 and 1)->HasChanges() == false, which triggers the exception

Can give the output from SetDebugLevel(2+) if needed too; been reading through it but can't make sense of it

This all might be a user error on my side though, i.e. I misunderstand how "update" 's behavior is supposed to be, relative to "install" behavior

[ttcoder]

And a third data point I forgot to mention, in case it's useful: "update" responds as expected if provided the dependancy with the local file:

/boot/system/cache/tmp/tts_updater_temp> pkgman update --home armyknife-5.1.8.0-1-x86_gcc2.hpkg ttscore_mimeconfig-2016.1-1-any.hpkg
Downloading repochecksum-1...done.
Validating checksum for Haiku...done.                                           
Downloading repochecksum-1...done.
Validating checksum for HaikuPorts...done.                                      
The following changes will be made:
  in home:
    upgrade package ttscore_mimeconfig to 2016.1-1 from local file
    upgrade package armyknife to 5.1.8.0-1 from local file
Continue? [y/n] (y) : n

[bonefish]

I'm not entirely sure what the semantics of providing a local package file for an update is (regarding libsolv's solver). Generally updating a package means to install the greatest installable version for that package. So, providing a concrete file for a package X probably has two effects: 1. add the package file to a high priority (virtual) repository and 2. update package X using the available repositories (preferring the virtual one). IOW the net effect would be the same, if you had added a real repository (with the highest priority) containing the package and just requested pkgman update --home armyknife. If a package version in any of the available repositories would theoretically match but cannot be installed, it is simply ignored when an update is requested. Hence the result "Nothing to do.", because nothing can be updated.

I think providing a package file to pkgman update, while possible, is only marginally useful. If you really want to install that version, use pkgman install.

So regarding this ticket, I tend towards "won't fix" (or "not really broken, just surprising semantics").

[ttcoder]

Will-not-fix sounds ok to me thanks to the clarified semantics:

If "update X.hpkg" really maps to "update X, with X.hpkg being just one possible source to retrieve X" then it makes sense: I would not expect "update Y" to report any possible problem related to Y on any repository where it lives.. (or maybe a --diagnose-verbosely command-line switch could be added some day?, if the underlying API provides supports it and if it makes sense at all :-).

So the ball is in my court now -- notes to self:

• maybe just switch my code to using the API's equivalent of "pkgman install" ? I think I had resisted that in the past in case that'd accidentally downgrade instead of upgrade (not likely to be a problem!!), and so as to preserve the package selection, if e.g. a user has installed tuneprepper.hpkg but not tuneprepper_extra_goodies.hpkg (but come to think of it, IIRC "update" and "install" actually behave the same on that front, both of them install the whole set of passed files). So no rationale any more for using "update"
• if for some reason I keep using "update" I gotta impress on Dane, even more than I already did :-), that he must always keep the roll-out package "sets" as current and as clean as possible, to avoid ending up with a "Nothing to do" message which would be difficult to diagnose

Some day we might switch to making our pkg roll-outs use actual hpkR repos, which might help with this (if the package_repo does some dep checking) and would definitely help with speed/efficiency Let's close this