[packagekit] exclude some upgrades
rnorwood at redhat.com
Mon Nov 12 12:17:48 PST 2007
Richard Hughes <hughsient at gmail.com> writes:
> On Mon, 2007-11-12 at 13:58 -0500, David Zeuthen wrote:
>> On Mon, 2007-11-12 at 18:14 +0000, Richard Hughes wrote:
>> > > Fair enough. packagekit won't be very useful as an update tool in ,
>> > > rawhide then but I can live with that.
>> I was trying to convey this is a problem with stable releases too. Users
>> install all sort of 3rd party RPM's and given that RPM's has file deps
>> the update can't happen. It's naive to think that this is not a problem
>> with stable releases. Do you disagree?
> Well yes. You're making the user do something clever because the repo
> has done something dumb.
Well, it's not just something that happens in a single repo, though. I
think this will most often happen with normal users who use multiple
repos. Ala livna + fedora.
>> - User tries to update system
>> - Transaction can't happen
>> - Some magic in the PacakgeKit yum backend to figure out the biggest
>> possible set that actually will make the transaction happen (hint:
>> look at a yum plugin that actually does this)
> Sure. Either we do this in the yum plugin or we handle this in the
> yumBackend.py file.
Is this something that never happens in other distros/packaging systems?
If so, then I can see why we might want to put the logic in the
yum-specific parts. Otherwise, if it's something than can be handled in
an abstract way, why not put it in the engine so all backends can
>> - User is informed of this by PackageKit showing the update list
>> but with some of the packages unchecked (GtkCheckButton)
> No, if a user can't be applied then it shouldn't be shown in the package
> update list. The update list shows "updateable" packages.
Hrm. In a way, this makes sense - but then how should PK tell the user
that there are packages that can't be updated? Also, I think at least
with the yum backend, testing the update set before displaying it to the
user will take much longer than just showing the available updates. I
could be mistaken, though.
o PK attempts an update
o Update fails because of deps
o PK does the updates it can do, and reports the parts it couldn't.
o PK brings up a dialog, and shows the user which ones it can't do, and
lets the user Continue and do the updates it can do, or Cancel.
>> - User reviews the checked updates and presses update
>> - Life goes on
> Except if you've checked the "automatically update" checkbox. Then you
> can't review anything.
>> > > Would you consider a "install only this one package"
>> > > button ?
>> > Totally, it's a good idea. Give me two minutes.
>> Uhm, that was actually what I was suggesting with saying the user should
>> be able to cherry-pick updates.
> No, I've added a button to the detail viewer, so that a user can click
> kernel - get all the info - and then just install this specific update.
> I don't think check boxes are the way to go at all.
Check boxes are pretty much useless in such a long list, I agree.
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
More information about the PackageKit