[Yum-devel] tsInfoDelta curiosity

[Florian Festi]

seth vidal wrote:
> On Fri, 2007-03-23 at 03:13 -0400, seth vidal wrote:
>> Hey,
>>   I was looking at the tsInfoDelta code that James first added and then
>> at the patch that Florian sent and something worries me. Take the
>> following case from:
>>
>>
>> quux requires bar
>>
>> quux is in a repository
>> bar is installed on the system
>>
>> I run the following yum shell commands:
>>
>> install quux
>> remove bar
>> ts solve
>>
>>
>> 3.1.X will remove bar and install quux leaving quux with a broken dep. -
>> something that I'll work on fixing shortly.
>>
>> 3.0.X will bitch at you and complain that the dep on bar is
>> unresolveable.
>>
>> I'm curious how we will ever be able to handle the above situation
>> without rechecking all pkgs in the transaction on every change to the
>> transaction set.

>> Is there something I'm missing?
> okay, we might be able to scoot around this problem but I'll work on the
> following changes:
> 
> 1. make sure that every separate call to resolveDeps resets the
> tsInfoDeltas
>    - so that if someone does: install foo; ts solve; remove bar; they
> don't end up not rechecking foo in light of bar being removed
If the delta resolver really works resetting the delta is not needed. You 
just have to make sure that really every change gets into the delta. 
Removing and formaerly added package again has to be treated as a remove in 
the delta.

> 2. we probably need to enhance _checkRemove to make sure it does:
>    a. account for any installed pkg requiring anything provided by the
> pkg being removed
This should already be the case.
>    b. account for any package_to_be_installed/updated requiring anything
> provided by the pkg being removed
Yes, this is missing and the delta resolving can't work without.

The Depsolver.deps cache is another source of errors as it returns outdated 
information.

>     - I think it's just an ordering problem right now but I might end up
> with a separate semi-private method like _provideToPkg() but kinda the
> opposite (_requiredDep())

This whole searching looks a bit messy at first sight. May be consistent 
interfaces and implementations for all Prcos and different type of package 
sacks/piles would be useful. I see no reason why a transaction shouldn't be 
seen as a package sack and provide the same search functions as all others.

Moving the search functions to the right places will also make further 
optimization easier.

Florian