Non-versioned Obsoletes tags
On Sat, 01 Apr 2017 19:54:28 +0200, Igor Gnatenko wrote:
repo system 0 testtags <inline>
#>=Pkg: foo-static 1 1 x86_64
repo available 0 testtags <inline>
#>=Pkg: bar 1 1 x86_64
#>=Obs: foo-static
#>=Pkg: foo-static 2 1 x86_64
system x86_64 rpm system
poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy
keeporphans yumobsoletes
job update all packages
result transaction,problems <inline>
#>erase foo-static-1-1.x86_64@system bar-1-1.x86_64@available
#>install bar-1-1.x86_64@available
Here again, a single test is insufficient, if there is no commentary that
explains what the defined behaviour of the RPM backend is and that there
is no alternative solution. Only with documentation of defined behaviour
one could conclude that no other solution exists and that the shown
behaviour matches the test target.
If wanting to move forward, anyone raising doubts about the current
handling of non-versioned Obsoletes tags (and Obsoletes tags in general)
during update transactions, would need to start at the very beginning and
analyze how RPM (_not_ only "rpm -Uvh") can handle Obsoletes in sets of
installed *and* available packages. Based on that, one can come up with
strategies for depsolving based on repo/package metadata, such as
evaluation order of PRCO or whether and when to ignore older NEVR of a
package where multiple EVRs are found.
Some day I've had a fruitless discussion with Seth Vidal about behaviour
of "yum install foo" and whether it should fetch only the very latest
package that provides "foo", evaluating Obsoletes and updates already,
or whether it may install any old EVR it finds in the repos and only
handle available updates/uprades and Obsoletes in subsequent "yum update"
runs. Yum, for example, installed an old package release only to replace
it with an available update immediately afterwards when running "yum update".
Some of the behaviour of tools is based on arbitrary definition by
developers and possibly not because of strict technical requirements.
Behaviour could be changed, but not without agreement from the devs. If
you want to change something about handling non-versioned Obsoletes, the
whole thing must be examined at a much deeper level and under consideration
of any documentation there may be that gives a rationale about the behaviour
of current tools and backends.