[Yum-devel] [PATCH 04/10] Minor changes to default yum-cron settings.

James Antill james at fedoraproject.org
Fri Jul 29 16:59:41 UTC 2011


On Fri, 2011-07-29 at 12:42 -0400, Matthew Miller wrote:
> On Fri, Jul 29, 2011 at 12:12:15PM -0400, James Antill wrote:
> >  I pushed everything but this patch.
> 
> Cool, thanks.
> 
> > > This sets MAILTO to root by default, instead of empty. The script still
> >  This seems fine, to me.
> 
> Do you want a separate small patch for just this change?

 No need to unless you are desperate to get it upstream ASAP. Shouldn't
take too long to work out what to do with this.

> > > Second, DEBUG_LEVEL is set to 1, so that a useful, basic amount of
> > > information is included in the updates.
> >  This I'm less sure about ... I know a lot of people complain about
> > output from yum-cron ... do you have examples of before/after of what
> > the above change does?
> 
> It's the difference between silence and:
> 
> ================================================================================
>  Package         Arch          Version                     Repository      Size
> ================================================================================
> Updating:
>  binutils        x86_64        2.21.51.0.6-6.fc15          updates        3.3 M
> 
> Transaction Summary
> ================================================================================
> Upgrade       1 Package(s)
> 
> Total download size: 3.3 M

 Right, and I'm 99% sure some people don't want that output in at least
some cases.


> >  Anyone else have an opinion?
> 
> I actually don't think the current options make much sense. The yum commands
> aren't consistent -- check-update gives output if there are packages
> available even with debuglevel set to 0, while update, which actually _does_
> something, is silent. And the mail is generated if there's any output.

 Personally I think we probably have a bunch of usecases, and yum-cron
should just have "commands" for each one and then we can get rid of the
verbosity configuration completely. At a guess for four common usecases:

1. Download all updates, so I can update whenever I want without hitting
the network.
  Output = Only output if something fails.

2. Show me the updates, so I can see what machines need to be updated.
  Output = "yum -q check-updates"

3. Automatically update my machine (or groupupdate).
  Output = Only output if something fails.

4. Automatically update my machine (or groupupdate), but show me.
  Output = "yum history info" + errors?

> What I'd like to do is have the script better know if the action was
> successful and what the results were (i.e. were updates available and/or
> applied?) and have it configurable at a high level whether you want e-mail
> reports on errors only, errors and warnings, on all changes, or on all runs,
> and how verbose you want each report to be.

 Sounds like we are in 100% agreement :).



More information about the Yum-devel mailing list