On Fri, 31 Mar 2017 21:10:29 +0100, Tomasz Kłoczko wrote: > According to those two "laws" at the moment *I think* that what it was > codified in FPG was caused by something stupid :) > Lets say .. it was something like misinterpretation when in on upgrade test > package from 2.0 to 3.0 someone forgot to remove "Obsolete: test-static". > At the moment it is IMO *only* working hypothesis that it was exactly > something like this, Other even less likely possibility is that it some bug > in rpm (IMO possibility close to zero) With all due respect, while trying to reinvent the wheel is not a bad idea in general sometimes, throwing away the experience bears many risks. Again you restrict yourself to that over-simplified scenario, where it's the same package that governs the Obsoletes tag *and* the [sub]package to obsolete. In reality, that's not case always. In order to remove a previously introduced Obsoletes tag, you would need to do what exactly? Replace the package, which contains that tag, wherever it is found. Where exactly is that? And how to achieve that? Suppose it's LibreOffice that has replaced a plugin, which would be reintroduced as a separate package. Would you release a superfluous update to everyone only to remove an Obsoletes tag? Or if it were a kernel package replacing a separate kernel-module driver package, would you release a superfluous kernel update to everyone only to remove an Obsoletes tag? Btw, that wouldn't even work, because multiple releases of such packages can remain installed. And in the repos, multiple releases of a package remain available to be accessed by the users. It may be multiple releases spread to multiple repos or multiple releases in a single updates repo even. If you wanted to restrict yourself to a single package release in all enabled repos, you would also need to delete an old build originally published at dist release time, because it had added an Obsoletes tag you wanted to remove. Keeping the package in the repo, but hiding it from the metadata (as in only offering latest EVR but not obsolete ones) would not be any different. We've come a long way, and returning to day zero and repeating some mistakes is not a good idea. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
