-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 2017-04-03 at 11:18 +0200, Michael Schwendt wrote: > 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. That wasn't call to change anything, it was example why we MUST stick with versioned obeolstes. RPM behavior is not interesting because it is just evaluating constraints, nothing else. Interesting thing is depsolving - libsolv. > > 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. I don't want to change anything, I'm pretty happy with current guidelines (moreover, I was asking to make ALL obsoletes versioned some months ago but didn't got to the point of mass bug filing). > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
- -- - -Igor Gnatenko -----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----- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
