8340 2015-09-20 22:26:23 +0000 libopkg needs a better error reporting mechanism (old issue #63) 2021-07-08 17:04:58 +0000 1 1 6 Yocto Project Subprojects opkg opkg unspecified x86 Multiple ACCEPTED Undecided enhancement next-minor 1 alejandro.delcastillo alex.stewart alex.stewart --- --- No (bug/feature does not impact docs) oldest_to_newest 54317 0 alejandro.delcastillo 2015-09-20 22:26:23 +0000 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. 54318 1 2750 alejandro.delcastillo 2015-09-20 22:27:34 +0000 Created attachment 2750 send_collected_err_to_stderr 62461 2 alex.stewart 2016-05-25 20:53:31 +0000 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. 82571 3 alejandro.delcastillo 2018-12-20 23:57:11 +0000 Re-targeting in preparation for 0.4 release 2750 2015-09-20 22:27:34 +0000 2015-09-20 22:27:34 +0000 send_collected_err_to_stderr send-collected-err-to-stderr.patch text/plain 559 alejandro.delcastillo ZGlmZiAtdU5yIG9wa2ctb3JpZy9saWJvcGtnL29wa2dfbWVzc2FnZS5jIG9wa2cvbGlib3BrZy9v cGtnX21lc3NhZ2UuYwotLS0gb3BrZy1vcmlnL2xpYm9wa2cvb3BrZ19tZXNzYWdlLmMJMjAxMS0w OC0wMSAxOTo0Nzo1MS45ODYwNjMyOTMgLTA0MDAKKysrIG9wa2cvbGlib3BrZy9vcGtnX21lc3Nh Z2UuYwkyMDExLTA4LTAxIDE5OjQ5OjM4LjcxMzgzMzkyNSAtMDQwMApAQCAtNjQsMTAgKzY0LDEw IEBACiAJc3RydWN0IGVycmxpc3QgKmVyciA9IGVycm9yX2xpc3RfaGVhZDsKIAogCWlmIChlcnIp IHsKLQkJcHJpbnRmKCJDb2xsZWN0ZWQgZXJyb3JzOlxuIik7CisJCWZwcmludGYoc3RkZXJyLCAi Q29sbGVjdGVkIGVycm9yczpcbiIpOwogCQkvKiBIZXJlIHdlIHByaW50IHRoZSBlcnJvcnMgY29s bGVjdGVkIGFuZCBmcmVlIHRoZSBsaXN0ICovCiAJCXdoaWxlIChlcnIgIT0gTlVMTCkgewotCQkJ cHJpbnRmKCIgKiAlcyIsIGVyci0+ZXJybXNnKTsKKwkJCWZwcmludGYoc3RkZXJyLCAiICogJXMi LCBlcnItPmVycm1zZyk7CiAJCQllcnIgPSBlcnItPm5leHQ7CiAJCX0KIAl9Cg==