[packagekit] running without a head via cron

[Matthew Miller]

On Thu, Mar 06, 2008 at 05:21:51PM +0000, Richard Hughes wrote:
> 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)?

Well, if there's a shell helper there, something incredibly trivial. Like
"exec /usr/sbin/the-real-thing". :)

> 
> >  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 $?.

As long as $? gives meaningful different results. It's nice to distinguish
between transient errors, and between "Updates installed, with notes"  and
regular "Updates installed" in the subject line.

> >  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.

That's one level of it. The next level is: if we were unplugged from the
network for three hours, we probably don't want to complain. If we're
unplugged for a day, maybe we want to make a little bit of noise. If we're
unable to get updates for a week, we want to be louder about it. But at the
same time, we don't want to annoy people with a storm of messages. 


> >  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.

The problem is there's a lot of potentially useful data. Even packagename +
old version + new version is straining what one can fit on an 80-character
line. Origin repository is pretty vital too, although perhaps one can group
packages into lists per repo, making that a sub-header rather than a column.
Then there's security vs. bugfix and other metadata. And then all of the
possible error reporting. So, that complicated styling and templates come in
handy.

> 
> >  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.

Well, that's just one example. :)


> >  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.

Yep, that'd be fine. But adding stuff like that gets more and more
complicated in a shell script.


> 
> >  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.

At this point, the python client library seems a bit more complicate than
that. :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>