<p dir="ltr">On May 28, 2016 4:20 AM, "Dmitry Smirnov" <<a href="mailto:onlyjob@debian.org">onlyjob@debian.org</a>> wrote:<br>
><br>
> On Friday, 20 May 2016 12:50:48 AM AEST Austin English wrote:<br>
> > I understand that there's a *potential* problem.<br>
><br>
> Potential problem of breaking APT operations is much more dangerous than<br>
> "actual" problem of ignoring return values.<br>
><br>
><br>
> > But<br>
> > here we have an *actual* problem, where the script is silently ignoring<br>
> > errors which is causing problems in downstream, and as far as I can<br>
> > tell, the current solution is to ignore actual errors in favor of<br>
> > preventing *potential* solutions?<br>
><br>
> That's right. Script was not intended to be used directly to begin with.<br>
> It was designed to be run automatically at the end of APT operations and<br>
> (re-)build passenger package when required.<br>
><br>
><br>
> > What exactly needs to be tested in the current packaging scheme so that<br>
> > behavior could be changed? I volunteer to help with that, if it's made<br>
> > clear what needs to be done.<br>
><br>
> Perhaps to temporary break script to always return error value and try<br>
> various apt operations (e.g. install, remove and reconfigure of other<br>
> packages) when post-invoke hook is activated to perform build or update.<br>
><br>
> We need to be absolutely sure that build/install errors do not propagate<br>
> where they does not belong and that nothing got broken if we take<br>
> responsibility for propagation of those errors.<br>
><br>
> --<br>
> Best wishes,<br>
>  Dmitry Smirnov.<br>
><br>
> ---<br>
><br>
> Without doubt you are not sane.<br>
>         -- Tage Danielsson</p>
<p dir="ltr">Thanks for reply Dmitry, I'll put this on my backlog. </p>