headers
Javier Palacios | 18 Nov 2010 11:48
Picon

Re: opkg return codes

On Wed, Nov 17, 2010 at 11:49 PM, Graham Gower
<graham.gower@...> wrote:
> On 18 November 2010 04:28, Jin <jin@...> 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
(Continue reading)

Permalink | Reply |
headers
Sergey 'Jin' Bostandzhyan | 18 Nov 2010 13:47
Favicon

Re: opkg return codes

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".

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.
(Continue reading)

Permalink | Reply |
headers
Graham Gower | 18 Nov 2010 23:49
Picon

Re: opkg return codes

On 18 November 2010 23:17, Sergey 'Jin' Bostandzhyan <jin@...> wrote:
> 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.
(Continue reading)

Permalink | Reply |
headers
Sergey 'Jin' Bostandzhyan | 19 Nov 2010 21:57
Favicon

Re: opkg return codes

On Fri, Nov 19, 2010 at 09:19:00AM +1030, Graham Gower wrote:
> 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.
(Continue reading)

Permalink | Reply |
headers
Sergey 'Jin' Bostandzhyan | 22 Nov 2010 11:33
Favicon

Re: opkg return codes

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.

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

--

-- 
You received this message because you are subscribed to the Google Groups "opkg-devel" group.
(Continue reading)

Permalink | Reply |
headers
Graham Gower | 23 Nov 2010 00:50
Picon

Re: opkg return codes

On 22 November 2010 21:03, Sergey 'Jin' Bostandzhyan <jin@...> wrote:
> 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
(Continue reading)

Permalink | Reply |
headers
Sergey 'Jin' Bostandzhyan | 23 Nov 2010 12:47
Favicon

Re: opkg return codes

On Tue, Nov 23, 2010 at 10:20:32AM +1030, Graham Gower wrote:
> > 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

--

-- 
You received this message because you are subscribed to the Google Groups "opkg-devel" group.
To post to this group, send email to opkg-devel@...
To unsubscribe from this group, send email to opkg-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/opkg-devel?hl=en.


Index: libopkg/opkg_remove.c
===================================================================
--- libopkg/opkg_remove.c	(revision 586)
+++ libopkg/opkg_remove.c	(working copy)
 <at>  <at>  -170,6 +170,7  <at>  <at>
(Continue reading)

Permalink | Reply |
headers
Graham Gower | 24 Nov 2010 01:02
Picon

Re: opkg return codes

On 23 November 2010 22:17, Sergey 'Jin' Bostandzhyan <jin@...> wrote:
> On Tue, Nov 23, 2010 at 10:20:32AM +1030, Graham Gower wrote:
>> > 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
>

Applied. Thanks!
-Graham
Permalink | Reply |
headers
Sergey 'Jin' Bostandzhyan | 24 Nov 2010 12:44
Favicon

Re: opkg return codes

On Wed, Nov 24, 2010 at 10:32:54AM +1030, Graham Gower wrote:
> > Indeed... here is the updated patch. I now also check the error code of
> > remove_autoinstalled() and propagate it accordingly.
> 
> Applied. Thanks!

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
Permalink | Reply |

Gmane