[Foresight-devel] Re: pinned kerneloops
Ken VanDine
ken at vandine.org
Tue Jun 17 12:48:29 EDT 2008
Good point, pulling from hg might be nice too. However, rss means
someone has to make the conscience decision to publish the scripts
On Tue, 2008-06-17 at 11:43 -0500, Kevin Harriss wrote:
> On Tue, Jun 17, 2008 at 11:38 AM, Ken VanDine <ken at vandine.org> wrote:
>
> [snip]
>
>
> I have thought allot about cleanup/automated maintenance
> operations,
> like unpinning older kernels. A couple ideas I have had,
> using
> PackageKit, before every check for updates run some script (or
> directory
> of scripts). This takes advantage of PK scheduling and
> handles things
> before update. Downside is users that just use conary command
> line
> never get the tidy scripts. However, those are users that
> might want to
> manage things themselves anyway. I also thought it would be
> cool to
> fetch the tidy scripts from the web, perhaps an rss feed. So
> all we
> need to do is publish references to the scripts and they get
> fetched
> before the next update check. This gives us the out of band
> control we
> might want. Thoughts?
>
> I think this is a good idea as some new users might be confused by
> having 20 kernels on their system. In regards to pull the scripts
> from RSS is that really better than pulling from an hg repo. I am
> just wondering what the benefits of publishing via rss is over
> publishing a hg repo.
>
> Kevin
>
>
> --Ken
>
>
>
> On Tue, 2008-06-17 at 12:03 -0400, Jack Doerner wrote:
> > Not that I'm any expert, but I don't think PackageKit really
> does
> > provide error messages to the user... or at least I've never
> observed
> > it doing so.
> > I'm surprised that conary doesn't have a way to unpin things
> in an
> > update... seems like it would be a good feature.
> >
> > On a similar, but off topic note - it would be nice if
> kernels that
> > had been on the system for a while got unpinned and removed
> when they
> > got older, so that you don't have too many kernels taking up
> space
> > that you don't need. This would be especially good for more
> novice
> > users who don't know how to use conary to remove them.
> Perhaps somehow
> > though (and I'm way over my head here as to how) it could
> only affect
> > kernels pinned by the computer, and not manually pinned
> kernels.
> >
> > On Tue, Jun 17, 2008 at 12:00 PM, Jack Doerner
> <jackbnymbl at gmail.com> wrote:
> > > Not that I'm any expert, but I don't think PackageKit
> really does
> > > provide error messages to the user... or at least I've
> never observed
> > > it doing so.
> > > I'm surprised that conary doesn't have a way to unpin
> things in an
> > > update... seems like it would be a good feature.
> > >
> > > On a similar, but off topic note - it would be nice if
> kernels that
> > > had been on the system for a while got unpinned and
> removed when they
> > > got older, so that you don't have too many kernels taking
> up space
> > > that you don't need. This would be especially good for
> more novice
> > > users who don't know how to use conary to remove them.
> Perhaps somehow
> > > though (and I'm way over my head here as to how) it could
> only affect
> > > kernels pinned by the computer, and not manually pinned
> kernels.
> > >
> > > On Tue, Jun 17, 2008 at 11:04 AM, Ken VanDine
> <ken at vandine.org> wrote:
> > >> So this means there will appear to be a failed update,
> and when they try
> > >> again things will work right (meaning we already unpinned
> kerneloops and
> > >> fixed the regex in that rbuilder generated conary config
> file)
> > >>
> > >> That isn't to bad.
> > >>
> > >> --Ken
> > >>
> > >> On Tue, 2008-06-17 at 10:56 -0400, Michael K. Johnson
> wrote:
> > >>> 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.
> > >>> _______________________________________________
> > >>> Foresight-devel mailing list
> > >>> Foresight-devel at lists.rpath.org
> > >>> http://lists.rpath.org/mailman/listinfo/foresight-devel
> > >>
> > >> _______________________________________________
> > >> Foresight-devel mailing list
> > >> Foresight-devel at lists.rpath.org
> > >> http://lists.rpath.org/mailman/listinfo/foresight-devel
> > >>
> > >
> > >
> > >
> > > --
> > > Jack Doerner
> > >
> > > There are worse crimes than burning books
> > > One of them is not reading them.
> > > -Joseph Brodsky
> > >
> >
> >
> >
> > --
> > Jack Doerner
> >
> > There are worse crimes than burning books
> > One of them is not reading them.
> > -Joseph Brodsky
> > _______________________________________________
> > Foresight-devel mailing list
> > Foresight-devel at lists.rpath.org
> > http://lists.rpath.org/mailman/listinfo/foresight-devel
>
> _______________________________________________
> Foresight-devel mailing list
> Foresight-devel at lists.rpath.org
> http://lists.rpath.org/mailman/listinfo/foresight-devel
>
>
>
>
> --
> specialKevin
> Kevin Harriss
> http://www.foresightlinux.org
More information about the Foresight-devel
mailing list