opkg return codes
Jin
I am using the opkg command line client from cgi scripts, there's a
web interface on top of this, basically a configuration interface that
allows users to update their system.
Sometimes there are situations where opkg will fail, however the
return code does not always reflect failure.
I'd like to define error codes and make sure that the command line
client returns the appropriate code upon exit; this should make it
easier to use opkg from other scripts.
Would you accept such a patch and do you have any suggestions or a
preferred way of how you would like to see this implemented?
Kind regards,
Jin
Graham Gower
> Hi,
>
> I am using the opkg command line client from cgi scripts, there's a
> web interface on top of this, basically a configuration interface that
> allows users to update their system.
>
> Sometimes there are situations where opkg will fail, however the
> return code does not always reflect failure.
I don't doubt this, but can you give an example?
>
> I'd like to define error codes and make sure that the command line
> client returns the appropriate code upon exit; this should make it
> easier to use opkg from other scripts.
>
> Would you accept such a patch and do you have any suggestions or a
> preferred way of how you would like to see this implemented?
>
> Kind regards,
> Jin
All of opkg error reporting needs a major overhaul, I see this as
opkg's biggest outstanding flaw. Contributions would be greatly
appreciated.
I've previously stated that I don't like having large numbers of error
codes and would prefer to give meaningful error messages where
possible.
http://code.google.com/p/opkg/issues/detail?id=63
However, I would accept patches to support error codes as you suggest
if its done in a clean way. I mostly don't want a situation where
there are 5 error codes and none of them tell the user anything about
what happened - or 300 different codes and most of them are only used
once (pppd anyone?).
You may wish to look at libopkg parts introduced by Thomas Wood back
when opkg was started (opkg.c, revisions from 2008/2009 before I came
along and broke it all). This error reporting looked clean enough,
unfortunately it was never hooked into opkg properly and didn't really
report errors accurately. Potentially, this could be fixed.
I'd be interested to hear from other opkg users/devs think too.
-Graham
PS: I understand you're referring to command line return codes, but in
order to do that properly it needs to start with error codes from
lower level functions which get propagated upwards.
Javier Palacios
> On 18 November 2010 04:28, Jin <j...@mediatomb.cc> wrote:
>> Hi,
>>
>> I am using the opkg command line client from cgi scripts, there's a
>> web interface on top of this, basically a configuration interface that
>> allows users to update their system.
>>
>> Sometimes there are situations where opkg will fail, however the
>> return code does not always reflect failure.
>
> I don't doubt this, but can you give an example?
I can give you a good example for more useful return codes, although
it doesn't exactly cover the "opkg fail" scenario.
Running opkg list-upgradable returns 0 whether there are or not
packages to upgrade. In my opinion, giving 0|1 is much useful that
only printing the list of upgradable packages. Is true that line
counting the command output can be used to distinguish both situations
in a script, but is less cleaner, as would be detect by running and
actual upgrade with --noaction.
In my opinion, this is by far the best to suggest a change in return
codes, even if it does not reflect an actual error. I can imagine
other situations, as giving non-zero when you install an already
installed packages or run an upgrade when there is nothing to upgrade.
On the other side for actual opkg "internal" errors, I see not very
useful to expose in detail as command line return codes, with the only
exception of separate permanent and transient errors (as wrong url in
config vs. server unreachable or down). But that is already
implemented at least for update operation.
Javier Palacios
Sergey 'Jin' Bostandzhyan
> >> Sometimes there are situations where opkg will fail, however the
> >> return code does not always reflect failure.
> >
> > I don't doubt this, but can you give an example?
>
> I can give you a good example for more useful return codes, although
> it doesn't exactly cover the "opkg fail" scenario.
I need to make a setup and reproduce it, but I remember having situations
where one package out of a bunch of packages failed, but the whole upgrade
was considered "successfull".
Which leads me to yet another proposal: for some packages it might be
critical that the preinst or prerm scripts execute correctly. If they fail,
the upgrade/remove/etc. operation should be aborted (unless overriden with
some --force switch).
I suggest to define a special error code for the hooks, which would cause
opkg to abort further proceedings. The package maintainer should decide
how critical a successfull execution of a hook is and choose the return
codes appropriately. What do you think?
> Running opkg list-upgradable returns 0 whether there are or not
> packages to upgrade. In my opinion, giving 0|1 is much useful that
> only printing the list of upgradable packages. Is true that line
> counting the command output can be used to distinguish both situations
> in a script, but is less cleaner, as would be detect by running and
> actual upgrade with --noaction.
Good idea, that would be helpful as well. I ended up writing an own app that
uses libopkg to do such things.
Kind regards,
Jin
Graham Gower
> On Thu, Nov 18, 2010 at 11:48:57AM +0100, Javier Palacios wrote:
>> >> Sometimes there are situations where opkg will fail, however the
>> >> return code does not always reflect failure.
>> >
>> > I don't doubt this, but can you give an example?
>>
>> I can give you a good example for more useful return codes, although
>> it doesn't exactly cover the "opkg fail" scenario.
>
> I need to make a setup and reproduce it, but I remember having situations
> where one package out of a bunch of packages failed, but the whole upgrade
> was considered "successfull".
Yes, I fixed this in r540.
> Which leads me to yet another proposal: for some packages it might be
> critical that the preinst or prerm scripts execute correctly. If they fail,
> the upgrade/remove/etc. operation should be aborted (unless overriden with
> some --force switch).
>
> I suggest to define a special error code for the hooks, which would cause
> opkg to abort further proceedings. The package maintainer should decide
> how critical a successfull execution of a hook is and choose the return
> codes appropriately. What do you think?
This should already be the case. If a script returns non-zero, this is
propagated back up the call chain. It should cause opkg to bail out,
or at least return non-zero in the event that other packages could be
operated upon (install,remove,configure,etc) but one failed.
>
>> Running opkg list-upgradable returns 0 whether there are or not
>> packages to upgrade. In my opinion, giving 0|1 is much useful that
>> only printing the list of upgradable packages. Is true that line
>> counting the command output can be used to distinguish both situations
>> in a script, but is less cleaner, as would be detect by running and
>> actual upgrade with --noaction.
>
> Good idea, that would be helpful as well. I ended up writing an own app that
> uses libopkg to do such things.
Yes, this seems reasonable.
>
> Kind regards,
> Jin
>
>
> --
> You received this message because you are subscribed to the Google Groups "opkg-devel" group.
> To post to this group, send email to opkg-...@googlegroups.com.
> To unsubscribe from this group, send email to opkg-devel+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.
>
>
-Graham
Sergey 'Jin' Bostandzhyan
> Yes, I fixed this in r540.
>
> > Which leads me to yet another proposal: for some packages it might be
> > critical that the preinst or prerm scripts execute correctly. If they fail,
> > the upgrade/remove/etc. operation should be aborted (unless overriden with
> > some --force switch).
> >
> > I suggest to define a special error code for the hooks, which would cause
> > opkg to abort further proceedings. The package maintainer should decide
> > how critical a successfull execution of a hook is and choose the return
> > codes appropriately. What do you think?
>
> This should already be the case. If a script returns non-zero, this is
> propagated back up the call chain. It should cause opkg to bail out,
> or at least return non-zero in the event that other packages could be
> operated upon (install,remove,configure,etc) but one failed.
Hmm, I do not see that happening with revision 585...
I have a package that needs to unmount an aufs mounted directory before
uninstalling itself, I can easily simulate the error case by going to
the directory that is supposed to be unmounted - this way umount will
return busy and the prerm hook will see that and do an "exit 1".
So here is what's happening when doing an opkg remove (error case in prerm
is triggered):
Collected errors:
* pkg_run_script: prerm script returned status 1.
root@system:/usr/share/dss/data# echo $?
0
Further, package deinstallation was not aborted, the package got removed
anyway.
I did not look into the code yet, actually I was planning to sit down and
have a go at this, I thought that was not yet implemented; so maybe there's just
a bug somewhere.
Kind regards,
Jin
Sergey 'Jin' Bostandzhyan
> > > I suggest to define a special error code for the hooks, which would cause
> > > opkg to abort further proceedings. The package maintainer should decide
> > > how critical a successfull execution of a hook is and choose the return
> > > codes appropriately. What do you think?
> >
> > This should already be the case. If a script returns non-zero, this is
> > propagated back up the call chain. It should cause opkg to bail out,
> > or at least return non-zero in the event that other packages could be
> > operated upon (install,remove,configure,etc) but one failed.
OK, I had a look at the code - opkg indeed bails out when the preinst hook
fails, it does not bail out when the prerm hook fails. I guess the latter
is arguable... what should be the default behavior?
Below is a patch that will cause opkg to abort package removal if the
prerm script of a package returns non zero. This can be overriden with the
--force-remove option which will ignore the return value of the script and
remove the package anyway.
The second patch adds the package name to the error message that is printed
when a script fails, this is quite useful, from time to time I had failed
hooks when upgrading a bunch of packages and it was never clear which of the
packages had problems.
Kind regards,
Jin
Graham Gower
> On Fri, Nov 19, 2010 at 09:57:06PM +0100, Sergey 'Jin' Bostandzhyan wrote:
>> > > I suggest to define a special error code for the hooks, which would cause
>> > > opkg to abort further proceedings. The package maintainer should decide
>> > > how critical a successfull execution of a hook is and choose the return
>> > > codes appropriately. What do you think?
>> >
>> > This should already be the case. If a script returns non-zero, this is
>> > propagated back up the call chain. It should cause opkg to bail out,
>> > or at least return non-zero in the event that other packages could be
>> > operated upon (install,remove,configure,etc) but one failed.
>
> OK, I had a look at the code - opkg indeed bails out when the preinst hook
> fails, it does not bail out when the prerm hook fails. I guess the latter
> is arguable... what should be the default behavior?
>
> Below is a patch that will cause opkg to abort package removal if the
> prerm script of a package returns non zero. This can be overriden with the
> --force-remove option which will ignore the return value of the script and
> remove the package anyway.
It does make sense to do this. What about the postrm script? Could you
update your patch to do something useful in the case that postrm
fails? Obviously, the package has already been removed, so maybe just
returning an error would suffice.
>
> The second patch adds the package name to the error message that is printed
> when a script fails, this is quite useful, from time to time I had failed
> hooks when upgrading a bunch of packages and it was never clear which of the
> packages had problems.
I have committed this.
>
> Kind regards,
> Jin
>
Thanks,
-Graham
Sergey 'Jin' Bostandzhyan
> > Below is a patch that will cause opkg to abort package removal if the
> > prerm script of a package returns non zero. This can be overriden with the
> > --force-remove option which will ignore the return value of the script and
> > remove the package anyway.
>
> It does make sense to do this. What about the postrm script? Could you
> update your patch to do something useful in the case that postrm
> fails? Obviously, the package has already been removed, so maybe just
> returning an error would suffice.
Indeed... here is the updated patch. I now also check the error code of
remove_autoinstalled() and propagate it accordingly.
Kind regards,
Jin
Graham Gower
Applied. Thanks!
-Graham
Sergey 'Jin' Bostandzhyan
> > Indeed... here is the updated patch. I now also check the error code of
> > remove_autoinstalled() and propagate it accordingly.
>
Thank you too :) Now up to the next level...
As the first step we now return a generic non zero code, so scripts have the
ability to figure out if the whole operation succeeded or not.
Now, it would be nice if the error code would indicate the type of failure,
i.e. failed preinst hook, failed prerm hook, failed postrm hook, network
failure, etc. This way scripts would be able to react appropriately and
propagate a meaningful message to the user.
Since opkg often operates on a bunch of packages at once, it might be helpful
to define some sort of "importance order" for the errors, so that the most
critical one is used as the return code.
I'll have a look at the earlier opkg revisions as you suggested, let's see
how it was done back then.
Kind regards,
Jin