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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
