[packagekit] exclude some upgrades

[Robin Norwood]

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
benefit?

>>  - 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.

What if:

o PK attempts an update
o Update fails because of deps

Automatic mode:

o PK does the updates it can do, and reports the parts it couldn't.

Interactive mode:

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.

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching