Re: 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.

_______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljiFj4ACgkQaVcUvRu8 X0yAoA/+Kcddo90AS9tBg7XLLn39P9sR/ly+i4n7en8sGr1C8PEWV0N3J4914UjR /lAxW4s62evq4/d9xKhWI+EGIcufCweS8/egpJq3EVmStSujJoPZJlhoxiwKQeWV MHxr5iPuu/oUeDCHecXHkfhGC3bG1ok6PjTvC129ABEYhJrSEkA1rC9yZgUm3pFa l3MrPIoT+R9SzTjYaIFYSI6drE9hnU+sF9aVMYfPzSdLiSM2Mi0oj7bVU28mhxJ3 9O6BkHowXOFP3s7WA2asBSw7LETe74htXGRmlEovppcJwYmd12qHF7EM+YakfMVk rBxkM4JEmPjGjp9GVRvtLWHf+FTo41amz+i+WU6Caaa1M7APymoy+sVk5Dlu4iM1 Tfpzj/Y8FlzI6bPcqu7YuKHF7ckWRlXY8h/gVspBFm1RZPxy8WnTpCEUGZ9L0C4r GycIREUYFWMk82Vu822qJwGSx4TmqDfcsvyNSgsUdxqRL9L051LC3cKtmohl+vJn BWJWTTu5fWf0eUFDwzwhGHpL+9zKeUkxSZnkIFnc/Fm+FalcXLZQTeZbKqhXR6rs PKDwkP2guLmrxCGjpnSMk/qaDamZuQPYrpXecVlF+5L9Lke/mqKdHrmHN7F8smcN 1UkkBSF9meITMlnvJTSJzEdOwv9DSh8Ok44c4hhRiTlq0Cv/U1I= =HhcG -----END PGP SIGNATURE-----