[Foresight-devel] Re: pinned kerneloops

[Michael K. Johnson]

On Tue, Jun 17, 2008 at 10:56:18AM -0400, Michael K. Johnson wrote:
> 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

I think this would look like this (untested...):

if conary q kerneloops --info | grep 'Pinned.*: True' >/dev/null 2>&1 ; then
    echo 'unpinning kerneloops, retry update soon'
    (i=0;
     while [ $i -lt 30 ] ; do
         sleep 1;
         conary unpin kerneloops
         if  conary q kerneloops --info | grep 'Pinned.*: True' >/dev/null 2>&1 ; then : else
            exit 0
         fi
         i=$(($i+1));
     done >/dev/null 2>&1)&
     exit 1
fi


Note that we'll have to leave this in place indefinitely.  Also, note
that this might hit a user twice: once on the first time the update
happens to a group that has this script and that also references an
/etc/conary/config.d/kernel that has a restriced pinTroves entry,
and the second time on the subsequent update, since the current
pinTroves will apply to the conary update that first fixes kerneloops...