On 8 June 2012 23:43, Manuel A. Fernandez Montecelo <[email protected]> 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. _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
