[packagekit] running without a head via cron
mattdm at mattdm.org
Thu Mar 6 11:04:21 PST 2008
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
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
> > 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
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
Matthew Miller mattdm at mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
More information about the PackageKit