| Summary: | libopkg needs a better error reporting mechanism (old issue #63) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Yocto Project Subprojects] opkg | Reporter: | Alejandro del Castillo <alejandro.delcastillo> | ||||
| Component: | opkg | Assignee: | Alex Stewart <alex.stewart> | ||||
| Status: | ACCEPTED --- | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | Undecided | CC: | alex.stewart | ||||
| Version: | unspecified | ||||||
| Target Milestone: | next-minor | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
Created attachment 2750 [details]
send_collected_err_to_stderr
Additional info: Packages which are listed as dependencies, but not included in any sources are still added to the dependency graph and passed to the solver. When opkg is built with libsolv, the solver errors-out - unable to find the depended package in the sources - and opkg throws up error code 1 and passes libsolv's message that "- package <package> does not exist" This is different from the behavior when opkg is asked to install a package which is unlisted in the sources (even as a dependency). In this case, opkg throws error 255 and delivers to the user the low-level message: " * opkg_prepare_url_for_install: Couldn't find anything to satisfy '<package>'." These are, from the user's perspective, the same error; but they're delivered differently. From the developer's perspective, receiving the general errno 1 from the solver is unhelpful in handling the problem. Re-targeting in preparation for 0.4 release |
Users of libopkg have no reasonable way of determining the error from opkg. I don't like the idea of having a list of return codes with various meanings (a la errno), as this makes it difficult to give accurate information about specific errors. A function returning the last known error would be a good option (e.g. sqlite's sqlite3_errmsg()). Originally reported by graham.gower, Sep 21, 2010 ----------------------------------------------------------------------------- #1 denix0 (Aug 1, 2011) Here's a start - patch to send "Collected errors:" reports to stderr. Otherwise it's hard to deal with non-fatal errors (should they be warnings?) in scripts. #2 paul.betafive (Sep 18, 2013) The patch looks good, errors should definitely be printed to stderr not stdout. I'll try to get it applied for version 0.3. Also, I disagree with Graham here. Error codes are better because they're simpler to handle in code that wants to know what error occurred (use "==" rather than "strcmp"). It also means a function opkg_strerror(int err) can eventually give the error in a local language, knowing that no sane code is going to run strcmp on it. Maybe we need an error structure that can say what package or file caused the error code, something like: struct opkg_error { int err; char * cause; }; #3 paul.betafive (Feb 1, 2014) Drop back to v0.4.