[packagekit] running without a head via cron

[Richard Hughes]

On Wed, Mar 5, 2008 at 8:22 PM, Matthew Miller <mattdm at mattdm.org> wrote:
>  There's some significant advantages in having your controlling program (i.e.
>  that which gets run from cron) be something other than a shell script.

Do you mean gets run from cron directly, or via a trivial shell helper
(the thing in /etc/cron.daily)?

>  1) Error handling. If something goes wrong, we want a different message than
>    for success -- different subject, different body, etc. Plus, there's many
>    different types of errors (network problems, repo problems, local package
>    db problems, etc.) which need different responses.

Sure, but can't most of those messages be encoded into the message
body and a simple "Updates failed|Updates installed" be passed as the
header on result of $?.

>  2) Dealing with network transiency. This is a big enough issue that I want
>    to highlight it separately from error handling in general. Network errors
>    may be temporary, in which case we don't want to send out too many
>    annoying messages, but we may want to log a warning if they go on for too
>    long.

So you mean be able to keep retrying on error? That's not a bad idea
to add to the existing pkcon tool also as we can trivially
pk_client_requeue() on the PkClient object in the event of an error.
In normal use something like --retry-count=3 might be a useful option
to have. A patch to do that should be pretty easy for someone to cook
up.

>  3) Formatting output. Generally, utilities designed for command-line use
>    don't have output that's idea for e-mail. And, we probably want to also
>    have the option of sending HTML mail. But for obvious curmudgeonly
>    sysadmin reasons this must be optional.

I'm not sure HTML email is something I want to do - as soon as we
cross that bridge we have to worry about styling and templates and
stuff. Text emails are probably the way to go.

>  4) Avoiding writing temporary files for mail output. Temporary files just
>    add a whole 'nuther category of potential failures. (What if updates are
>    broken because /var is full?)

Well, I'm guessing var being full would cause a whole world of
failures, not just from pkcon, but from PackageKit (which writes to a
database in var for each new transaction). To be honest, I'm not sure
what packagekitd does when var is full or unavailable, and would be
useful for someone to give it a go with 0.1.9 and report back to the
list.

>  5) Creeping feature doom. It'd be nice to be able to set which repos get
>    updated automatically, which get only security updates, which get only
>    notification. Handling that in a shell script gets crazier and crazier.

PackageKit can't ask the backend to only update from certain repos, as
that would imply it could do it's own dependancy resolution. You can
however ask PackageKit to disable a repo, do the update then enable a
repo -- I think that would do what you require.

>  There's probably more. That's off the top of my head. :)

Well, I appreaciate your feedback.

>  So, I think it's ideal to not call a designed-for-the-CLI frontend from a
>  shell script, but rather replace the shell script with a
>  designed-for-background program.

Yes and no. We can make pkcon more shell-script friendly, for
instance, not displaying the progress bars when not attached to a
console. If we need to, we can break out new tools trivially and put
them in contrib for optional building. The PkClient library makes
writing such tools a ~20 lines-of-c job.

Richard