Bug 435628

Summary: interactoin between packagekit and yum-updatesd
Product: [Fedora] Fedora Reporter: Jeremy Katz <katzj>
Component: PackageKitAssignee: Robin Norwood <robin.norwood>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: mattdm, richard, tla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 0.1.9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-19 13:27:55 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235706    
Description Flags
packagekit with cron none

Description Jeremy Katz 2008-03-02 13:55:36 EST
There's some overlap here and I'm pretty sure we don't want both of them
running.  But yum-updatesd provides more functionality (especially in terms of
ways of notification) as well as not requiring a graphical session running for
it to be activated.

We need to reconcile this
Comment 1 Matthias Clasen 2008-03-02 23:09:20 EST
packagekitd doesn't need a graphical session to be activated either, afaics.
I admit it won't send mail.
Comment 2 Jeremy Katz 2008-03-03 14:10:44 EST
It has to be activated, though, and doesn't do checks unless someone logs in, etc.  

As opposed to being a system service that's available and is always checking
even if no one is logged in.  Especially for the case of doing automated
updates, the latter is nice/important.
Comment 3 Richard Hughes 2008-03-03 15:51:22 EST
Well, you can just put a simple dbus-send call in cron or even just execute
"pkcon --nowait update-system"

What feature of yum-updatesd do you think packagekit doesn't do? Which are
important? I guess there's the non-gui install thing (which is quite important)
and the email when updates, which I see as lessimportant.


Comment 4 Robin Norwood 2008-03-03 15:55:04 EST
Well, the update applet that we have now doesn't start unless someone logs in -
just like puplet.  But there's no reason why we can't add something equivalent
to yum-updatesd (or just modify yum-updatesd to call through PK instead of yum).
 To be honest, I haven't really looked at yum-updatesd much, so I don't know all
of it's functionality.  In pk-land does it need to be a daemon, or could it just
be a simple cron job?  Since we already have a daemon (packagekitd) to arbitrate
things, no sense in having another unless it's absolutely necessary.

Email/syslog updates are less important to 'desktop users', but critical for
sysadmins, I imagine.
Comment 5 Jeremy Katz 2008-03-03 22:32:40 EST
non-gui update is important, email is critically important according to a number
of users.  The syslog functionality we mostly did because it's cute and trivial
to do in python.  While not needed for the desktop user, these are very
important to users with a lot more machines.  Email and syslog become even more
important when you have the non-gui update as they serve as notification to the
admin of an update occurring (or failing)

As for starting on demand, I've mentioned a few times to dbus folks that a way
of doing periodic dbus activation that didn't depend on cron, etc would be nice
as really, cron just needs to die.  But no real movement on that front, hence,
yum-updatesd exists as a daemon.
Comment 6 Richard Hughes 2008-03-04 06:12:20 EST
Created attachment 296722 [details]
packagekit with cron

What about something like the attached?
Comment 7 Jeremy Katz 2008-03-04 11:09:34 EST
You also end up wanting some randomization so that you don't have every machine
in the world (or on your network) firing up to check for updates at the same time.
Comment 8 Richard Hughes 2008-03-04 11:51:44 EST
I've bodged a random time delay into the cron script and pushed this to master.
Comment 9 Matthew Miller 2008-03-05 14:47:24 EST
FWIW, I'm one of the users for whom e-mail updates are critical. Also, I'd like
the updates to be run at known times (with a minimal pause to avoid swamping
servers) rather than arbitrarily at fixed intervals. So while maybe cron needs
to die, that's exactly what it's good at and I don't see a big advantage in
reinventing it for every service.
Comment 10 Richard Hughes 2008-03-16 19:28:11 EDT
We have the cron script in git... can I now close this bug?
Comment 11 Robin Norwood 2008-03-19 13:27:55 EDT
and a PackageKit-cron package that installs said cron script for those who want
it.  Closing.