PackageKit does display the errors to the user, in a rather crude way. If an exception is raised, the output of that is wrapped in a notification bubble (i think, might be a dialog).
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? --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
