dnf update vs Software Udpates

Radek Holy rholy at redhat.com
Thu Jul 23 06:32:19 UTC 2015



----- Original Message -----
> From: "Suvayu Ali" <fatkasuvayu+linux at gmail.com>
> To: users at lists.fedoraproject.org
> Sent: Thursday, July 23, 2015 1:07:13 AM
> Subject: Re: dnf update vs Software Udpates
> 
> Hi Pete,
> 
> On Wed, Jul 22, 2015 at 05:42:15PM -0500, Pete Travis wrote:
> > 
> > There is a timer unit, `/usr/lib/systemd/system/dnf-makecache.timer`, that
> > fires ten minutes after each boot then one hour following the execution of
> > each previous run.  It triggers
> > `/usr/lib/systemd/system/dnf-makecache.service`, a service that executes
> > `dnf -v makecache timer`.  When that command runs, dnf will check the age
> > of the current metadata cache and refresh it if it is older than the value
> > of * metadata_timer_sync* (seconds) in `/etc/dnf/dnf.conf`.
> 
> Thank you for this clear and very nice explanation.
> 
> > So, an always-on computer should never have metadata older than 4 hours; in
> > practical terms, I think values >2 hours are increasingly unlikely.  A
> > computer that's been off overnight and turned on in the morning should have
> > a fresh cache within 15 minutes of boot.  If you have, say, a laptop that
> > you power down often and often install or update packages immediately after
> > boot, you might adjust the OnBootSec value by copying dnf-makecache.timer
> > to /etc/systemd/system/ and editing accordingly.  Or, consider appending
> > --refresh on an as-needed basis.
> 
> I think this is where things go wrong.  OnBootSec handles powerdowns,
> what about intermittent connections?  In principle, it is quite possible
> everytime the timer triggers the makecache service, the connection is
> absent.  In fact, the probability to hit the sweet spot is directly
> determined by the reliability of the connection.  So a connection that
> is up 50% of the time, will miss 50% of the makecache jobs.  Maybe the
> makecache jobs can reset the timer to try again in 10 mins in case of no
> network connectivity.  I think that would make the odds more favourable.
> 
> Essentially I'm suggesting to treat no connectivity as a powercycle.
> Hopefully this gives the devs some ideas.
> 
> Cheers,
> 
> --
> Suvayu

Can you please file an RFE?

Thanks
-- 
Radek HolĂ˝
Associate Software Engineer
Software Management Team
Red Hat Czech


More information about the users mailing list