Created attachment 4813 [details]
Introduce new exit code

Introduce exit code 3 for case where at least one update channel succeeds while at least one other did not.  The new exit code will allow wrapper scripts to run sa-compile even if a channel fails.

Created attachment 4814 [details]
Patch against svn

Sorry, the first patch was against the 3.3.1 release, but the svn version is slightly different.  The new patch is against the current svn trunk.

I chose a slightly different approach, intending to be a bit less fragile
and perhaps easier to read.

  Bug 6380: sa-update should handle case where some channel(s) fail
  but others work - introduce exit status 3"
Sending sa-update.raw
Committed revision 1028033.

Will attach the diff.

Here are some test results to demonstrate the behaviour,
the only change is an added status 3, split from the 4:

# sa-update -v; echo $?
Update available for channel updates.spamassassin.org
Update was available, and was downloaded and installed successfully
0

# sa-update -v; echo $?
Update finished, no fresh updates were available
1

# sa-update -v; echo $?
Update available for channel updates.spamassassin.org
config: failed to parse line, skipping, in ...
Lint of site pre files failed, cannot continue
Update failed, exiting with code 2
2

# sa-update -v --channel updates.spamassassin.org --channel xxx.rules.yerp.org; echo $?
Update available for channel updates.spamassassin.org
channel: no 'mirrors.xxx.rules.yerp.org' record found, channel failed
Update of at least one channel finished, other updates failed
3

# sa-update -v --channel xxx.spamassassin.org; echo $?
channel: no 'mirrors.xxx.spamassassin.org' record found, channel failed
Update failed, exiting with code 4
4

Created attachment 4817 [details]
my proposed patch

the r1028033 diff

Daryl writes:
> I can't access this bug for some reason.  I get an "undef error - Can't 
> locate Class/Singleton.pm" error.
>
> Any who... do we care about having error codes corresponding to binary 
> bits (the original codes were 0 1 2 4)?  Should the new error code be 8?

Kevin writes:
> I think it is a good idea to use binary bits because then if we need, we 
> can error with 12 and that's bitwise errors of both 4 & 8, etc. should 
> we decide to in the future.
> I can't test this because I don't use multiple channels but should be 
> add a test case?

Should the new error code be 8?  Perhaps. The docs and the code in sub
channel_failed implied that codes above 4 could be just an error count
(5,6,7,...), although apparently the counting in channel_failed() was
implemented incorrectly so it would never start counting errors, so
it seems there is no compatibility issue one way or another.
The Jasons's choice of 3 made use of the only free value complying
with the docs and not breaking compatibility.

A bitwise semantics of an error code would only make sense if combinations
of bit flags can actually occur and make sense. If more than one bit
can never turn on in practice, there is no value in assigning bits to
errors.

Let's see what are the possible outcomes currently:

 A. no errors,   no updates
 B. no errors,   some updates
 C. some errors, no updates
 D. some errors, some updates
 E. lint errors, updates available but not applied
 F. some other exit code as reported by import_gpg_key or GetOpt

Before assigning values, let's see what are sensible plans of action:

 A. none
 B. sa-compile
 C. warn
 D. sa-compile, warn
 E. alert
 F. alert

or inverted:
 sa-compile  if B or D
 warn        if C or D (or E or F)
 alert       if E or F

An additional constraint is that when everything is normal
the exit code should be zero!

Here is one attempt of assigning bits:
 bit 0:  not  some updates
 bit 1:  some errors or lint errors or other errors
 bit 2:  fatal errors like lint/gpg/GetOpt failures

So:
 if bit 0 is zero, run sa-compile
 if bit 1 is one, log a warning
 if bit 2 is one, log an alert

curr proposal
---- -----
 1   001=1  A. no errors,   no updates
 0   000=0  B. no errors,   some updates
 4   011=3  C. some errors, no updates
 3   010=2  D. some errors, some updates
 2   111=7  E. lint errors, updates available but not applied
 ?  x111=7+ F. some other exit code as reported by import_gpg_key or GetOpt

In the end - I don't know what would be the most sensible choice.
Current error codes never appear in combinations. Assigning sensible
semantics to each bit may require reshuffling values, which breaks
compatibility.

Thoughts?

closing, the current trunk (3.4) solution has been in use for one year