[Aptitude-devel] Please review: proposed changes to aptitude error reporting

[Daniel Hartwig]

On 8 June 2012 23:43, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> In my mind, the only errors that could be possibly useful to
> distinguish would be things like transient network failures, where
> scripts could decide to use other mirrors, or packages not yet present
> in the mirrors despite the indices being updated (there are bug
> reports about that), or something like that.

>  In these cases, at least
> one can retry (in the case that the download is incomplete) with some
> hope that the previous error would succeed (unlike, say, resolving
> package conflicts, which should always render the same result).

That is the primary use case I had in mind for status 2.  It is only
used by install actions at this point; most other commands are
naturally all-or-nothing :-)

Unresolved conflicts is always going to be fatal, with no actions taken.

>> Previously aptitude's exit status was very ad-hoc.  The use of 255 is
>> to remaining consistent with the current fatal exit status, however, I
>> believe this should definitely be changed to 100 for consistency with
>> apt-utils.
>
> Compatibility with apt-utils is good, IMO.

Indeed.  Since codes are changing I will definitely use 100 for the
fatal errors.  I still see value in 2, with an override to have
non-fatal errors exit in the same way that apt does.

As you say, most programs will only be interested in success or not.

> Apart from that, as said above, I suspect that most people using
> aptitude in this way would rely only on a boolean (SUCCESS|FAILURE),
> or at most taking into account user-cancelled codes; I don't think
> that many people check for the 255 explicitly.  I can be proven wrong,
> though :-)

I hope that no one is checking specifically for 255 either!

> Precisely, since it's unreliable now (and has been for so many years),
> I don't think that a change in the number of error code is going to
> cause much distress.

Unstable is as unstable does …

Any breakage due to a previously ill-defined exit status becoming
well-defined is hopefully going to be simple to fix.  A few tighter
checks here, less obscure work-arounds there.