[Yum-devel] Obsoletes Test Cases

[seth vidal]

On Tue, 2007-10-16 at 17:02 +0200, Florian Festi wrote:
> Hi!
> 
> Same test environment, same packages, same variations, new game: Obsoletes
> 
> Packages available in i368, x86_64 and noarch:
>   * Installed packages: zsh-1-1.arch - iarch
>   * Obsoleting packages (obsoletes: zsh): zsh-ng-0.3-1.arch - oarch
> 
> Additional there is
>   * A package requiring obsoleting package(s) (requires: zsh-ng): 
> superzippy-3.5-3.noarch - ro
> 
> Each test calls runOperation with 3 parameters:
>   * Command list
>   * Packages installed in the rpmdb
>   * Packages available in the repository
> 
> There is always one "yum update" test case that should handle the obsoletes 
> and then we have one test cases where the obsoleting package(s) are required 
> by the to be installed package ro (aka superzippy aka "Requires Obsolete").
> 
> testObsoletenoarchToMultiarch - works
>      runOperation(['update'], [inoarch], [oi386, ox86_64])
>      oi386, ox86_64 # ox86_64 only would be an alternative policy
> testObsoletenoarchToMultiarchForDependency
>      runOperation(['install', 'superzippy'], [inoarch], [p.oi386, p.ox86_64, 
> p.ro])
>      #ox86_64, ro
>      inoarch, ox86_64, ro
>      # likely to run into file conflicts, additional test case indicates 
> that "yum update" doesn't fix that problem as the obsolete is already 
> installed - yes, this is the "right behavior"
> 
> testObsoletei386ToMultiarch - works
>      runOperation(['update'], [ii386], [oi386, ox86_64])
>      oi386
> testObsoletei386ToMultiarchForDependency
>      runOperation(['install', 'superzippy'], [ii386], [oi386, ox86_64, ro])
>      #ox86_64, ro
>      ii386, ox86_64, ro
>      # similar to the case above - see below
> testObsoletei386ToMultiarchForDependencyFix # try if it goes away with "yum 
> update"
>      runOperation(['update'], [ii386, ox86_64, ro], [oi386, ox86_64])
>      ii386, ox86_64, ro
>      # yes, the obsolete is already installed - not removing ii386 is the 
> right thing here - but that doesn't help us...
> 
> testObsoletex86_64ToMultiarch - works
>      runOperation(['update'], [ix86_64], [oi386, ox86_64])
>      ox86_64
> testObsoletex86_64ToMultiarchForDependency
>      runOperation(['install', 'superzippy'], [ix86_64], [oi386, ox86_64, ro])
>      #ox86_64, ro
>      ix86_64, ox86_64, ro
>      # ...
> 
> testObsoleteMultiarchToMultiarch - works
>      runOperation(['update'], [ii386, ix86_64], [oi386, ox86_64])
>      oi386, ox86_64
> testObsoleteMultiarchToMultiarchForDependency
>      runOperation(['install', 'superzippy'], [ii386, ix86_64], [oi386, 
> ox86_64, ro])
>      #oi386, ox86_64, ro
>      ii386, ix86_64, ox86_64, ro
>      # ...
> 
> testObsoleteMultiarchTonoarch - works
>      runOperation(['update'], [ii386, ix86_64], [onoarch])
>      onoarch
> testObsoleteMultiarchTonoarchForDependency
>      runOperation(['install', 'superzippy'], [ii386, ix86_64], [onoarch, ro])
>      #onoarch, ro
>      ii386, ix86_64, onoarch, ro
>      # ...
> 
> Looks like packages added for dependency are not checked as possible 
> obsoletes. This explains all of the problems seen above. Normal obsoletes 
> seam to work quite well. Unfortunately the (correctly implemented!) 
> obsoletes semantic doesn't clean up the problems created by the installs for 
> dependencies.
> 
> Opinions?

In general, I'm getting the hang of the tests you've been submitting and
figuring out where/what we're missing. Good. I'm not so keen on the:
ii386 and ix86_64 syntax, or onoarch.

it's a good deal confusing to read. I realize it is probably for brevity
reasons but if we want to understand this later I think it might be good
to make it a bit more verbose.

-sv