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 <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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@lists.rpath.org > > >>> http://lists.rpath.org/mailman/listinfo/foresight-devel > > >> > > >> _______________________________________________ > > >> Foresight-devel mailing list > > >> Foresight-devel@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@lists.rpath.org > > http://lists.rpath.org/mailman/listinfo/foresight-devel > > _______________________________________________ > Foresight-devel mailing list > Foresight-devel@lists.rpath.org > http://lists.rpath.org/mailman/listinfo/foresight-devel > > > > > -- > specialKevin > Kevin Harriss > http://www.foresightlinux.org _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
