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.
root <at> 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