21e99b4766
Here's what happens: * BPackageManager created a BRefreshRepositoryRequest with a BContext of an empty DecisionProvider and itself. * Since there is no internet access, the FetchFileJobs that the refresh class queued fail. Specifically, the first one does, but then as the subsequent ones depend on it, they are all aborted. * As some jobs were aborted, the StateListener is notified. * The state listener of course has the BPackageManager class as one of the listeners, and so calls it, because even though the handler methods of BRefreshRepositoryRequest, they are powerless to stop event propagation. * The BPackageManager's highest subclass' implementation gets called, which is of course pkgman's. * pkgman decides to DIE() upon receiving word that a job was aborted. There are thus four potential solutions to this issue: * Rewrite the package kit's event & job handling systems to not be so screwed up in terms of propagation. Seriously, there is way too much stuff that we send to the "user" in here, and as you can see, it can get *extremely* convoluted even for supposedly "simple" tasks. This is probably the best "long-term" solution; but obviously is far too involved for the present. * Only partially rework event handling; specifically in the SupportKit to allow JobStateListeners to stop further propagation. This is probably the best "medium-term" solution. * Do not pass the package manager as the JobStateListener to the RefreshRepositoryRequest. This would have the downside that the regular notifications about download state, etc. would not be returned at all, which we don't want. We could make a shim ... but that would be a lot of code for little benefit. The prior solution makes more sense. * Completely ignore "JobAborted" notices in pkgman. In fact, this is the solution that virtually all other consumers of this API take (although some of them seem to have TODOs about it), including package_daemon, HaikuDepot, etc., and so it's the one I've taken here. If a "job aborted" error is actually fatal, then it's the Package Kit's problem. Fixes #13075. |
||
|---|---|---|
| 3rdparty | ||
| build | ||
| data | ||
| docs | ||
| headers | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .gitreview | ||
| configure | ||
| Jamfile | ||
| Jamrules | ||
| License.md | ||
| ReadMe.Compiling.md | ||
| ReadMe.md | ||
Haiku
Homepage | Mailing Lists | IRC Channels | Issue Tracker | API docs
Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.
Goals
- Sensible defaults with minimal configuration required.
- Clean, clear, concise code.
- Unified desktop environment.
Trying Haiku
Haiku provides pre-built nightly images and release images. Haiku is compatible with a large variety of hardware, but in case you don't want to "take the plunge" and install Haiku on bare metal, you can install it on a virtual machine (VM) instead. If you've never used a VM before, you can follow one of the "Emulating Haiku" guides.
Compiling Haiku
See ReadMe.Compiling.
Contributing
Haiku is a meritocratic open source project with a large variety of tasks. Even if you can't write code, you can still help! Haiku needs designers, (technical) writers, translators, testers... Get involved and help out!
Contributing code
If you're submitting a patch to us, please make sure you're following the patch submitting guidelines.
If you're having trouble finding something in the source tree, you can use one of our OpenGrok servers:
- http://xref.plausible.coop/ (provided by Landon Fuller)
- http://code.metager.de/source/xref/haiku (provided by MetaGer)
Contributing documentation
The main piece of documentation that still needs work are the API docs (found
in the tree at docs/user). Just find an undocumented class, write
documentation for it, and submit a patch.
Contributing translations
See wiki:i18n.
Contributing software ports
See HaikuPorts.
Contributing to our infrastructure
See Infrastructure.