Opened 9 years ago
Closed 9 years ago
#12560 closed bug (no change required)
"pkgman up ak.hpkg" misreports "Nothing to do" (whereas "pkgman install" is ok)
Reported by: | ttcoder | Owned by: | bonefish |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Package Kit | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
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
Change History (4)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
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").
comment:3 by , 9 years ago
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
comment:4 by , 9 years ago
Resolution: | → no change required |
---|---|
Status: | new → closed |
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: