[Yum-devel] [PATCH][RFC] Add skip-broken to YumBase

[Tim Lauridsen]

Florian Festi wrote:
> Hi Tim!
> 
> Having a first look over you patches the following comes to my mind:
> 
> Tim Lauridsen wrote:
>> I have created at patch to add skip-broken functionality to YumBase.
>>
>> I works the following way:
>> 1. I have added some code to the depsolver to store packages with 
>> problems in the self.po_with_problems dict. So we have the po with 
>> problems when the depsolving is completed.
>  * This should be a set. These key:1 dicts are ugly IMHO.


Agree, it should be a set (fixed)

>> 2. I have added a extra 'skip-broken' parameter to 
>> YumBase.buildTransaction to control if we want to skip packages with 
>> problem from the transaction. (default = no)
> May be this should be done by accessing a global config option.

Yes, this is the right way to do it. (fixed)

> 
>> 3. if the skip-broken parameter is True, then we do
>>
>>    While "There is problems"
>>        Remove the packages from the transaction
>>        Depsolve
> 
> 
>  * From my understanding of the architecture of the depsolver the 
> handling of po_with_problems should be done in the process* methods. But 
> that might be my personal taste.

Sounds sane to me, (fixed)

>  * Your patch fails to make sure that the problematic packages are not 
> readded by dependencies. If that happens you run into an endless loop. 
> The right solution would be an excluded_pkgs set that is ignored for all 
> depsolving operations. If pkgs are removed from the transaction they get 
> put into that set. This way we can never get back to the same situation 
> and can not run into an endless loop.

Added some code to clean out the added deps to a package with problems


>  * While your patch tries to keep the impact on the core code minimal 
> (which is a good idea for a first proof of concept implementation) I 
> think we need a deeper integration into the depsolver in the long run. 
> In fact there is no need of an outer loop around the depsolver. It would 
> be enough if the process* methods would just remove the problematic pkg 
> and adds them to the excluded_pkgs set.
Yes, Agree

>  * As your patch works on the packages that have problems and not on the 
> packages that cause the problems there might be interesting side effects.
Yes, this is the problem with trying to solve depsolve problem

foo-2.0 can't update foo-1.0, because bar require foo = 1.0.
So bar is causing the issue, foo-2.0, but i would not be sane to remove
bar. So we used remove foo-2.0 from the transaction, to get on with
other stuff.

>  * Like readding a package (by removing the erase txmbr) that has been 
> updated - resulting in the old and the new packages beeing installed 
> (welcome to the world of multilib file conflicts!)
I am not sure i understand this, please give some example.

>  * Although I added some code to handle removing transaction_members a 
> while ago this code still requires some testing to make sure everything 
> works fine.
>  * There's also still the Depsolver.cheaterlookup. You need to make sure 
> that nothing goes wrong with it (your patch should be ok, but some of 
> the stuff I sketched above might not)
> 
> Florian
> 

Thanks for your comments.

I have added a new patch with some of the changes you suggested.
I have added a new unittest to test it, without needing some special 
crafted rpms.

The patch also fixes some issues where a package is added to transaction 
by the depsolver, but the requering package is not stored in the 
TransactionMember.

Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: yum-skip-broken2.patch
Type: text/x-patch
Size: 8097 bytes
Desc: not available
Url : http://lists.baseurl.org/pipermail/yum-devel/attachments/20071120/ed7be1c6/attachment.bin