Bug 435628

packagekitd doesn't need a graphical session to be activated either, afaics.
I admit it won't send mail.

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.

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.

Thanks,

Richard.

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.

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.

Created attachment 296722 [details]
packagekit with cron

What about something like the attached?

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.

I've bodged a random time delay into the cron script and pushed this to master.

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.

We have the cron script in git... can I now close this bug?

and a PackageKit-cron package that installs said cron script for those who want
it.  Closing.