[Foresight-devel] pinned kerneloops

[Michael K. Johnson]

When kerneloops was added, no one noticed that the fact that we
pin kernel troves meant that the kerneloops program was pinned.
Now we're in a bind; we can't upgrade it without getting it unpinned.

There are two things to think about here:
 o  How to get it unpinned so that we can upgrade it.
 o  How to prevent this happening again.

Unpinning:

We can't unpin in a group script directly, because the conary
database is locked.  Fundamentally, any solution for this will be an
ugly hack; we just want to pick the one that is the least disgusting.
At least conary gives an error message that tells people (correctly)
how to unpin; this mitigates the problem.  One thing I don't know:
does PackageKit provide that error message to the user?

After much consideration, the only workable option I can come up
with is to could create a pre script which queries the database
(querying is OK, we just can't modify it) to see if kerneloops
is pinned, and if it is, it starts a disconnected background
job, then does "exit 1" to top the update.  The background
job would sleep/loop until it is able to unpin kerneloops.
See http://wiki.rpath.com/wiki/Conary:Group_Scripts

Prevention:

We should immediately fix the pinTroves entry in /etc/conary/config.d/kernel
to be more selective.  kernel:.* is probably good enough.  If not, then
we can use kernel(:.*|$) (need to test that, though).  This can be
done now, before we have finished testing the workaround that lets
us update kerneloops.