On 31 March 2017 at 17:57, Michael Schwendt <mschwe...@gmail.com> wrote:
> No, it's based on common experience several packagers have made over a > period of several years. You seem to have missed that period. Non-versioned > Obsoletes have caused problems before. > OK. Could you please show me example? Best if it will be documented for example in bugzilla. I'm almost sure that it is kind of mistake or results misinterpretation. It is yet another possibility tat it may be result of using yum/dnf which are working not exactly the same as rpm. [..] > > What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1" and just > > "Obsolete: A-static" when new 3.0 will arrive? > > > > What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was installed > > before? Of course A-static will be uninstalled. > > > > What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no longer > > carries Obsolete rule -> A and A-static will be upgraded together. > > No. The exact behaviour is implementation dependent. As long as the > Obsoletes tag is seen by the dependency resolver when examining installed > packages and available packages, the obsolete package is not taken into > consideration when resolving dependencies. Its EVR is irrelevant then. > It will not become an update or upgrade. It is obsolete. > > Below you added a wall of text once again. Your passion for this topic > is admirable, but it won't lead to anything, if you refuse to be much more > short and concise. > I have no idea about what kind scenario you are talking about so I made my tests. As I wrote engineering is about testing so here is my test case: Four spec files and two scripts. First one has: rm -f ~/rpmbuild/RPMS/x86_64/test* rpmbuild -ba --quiet test-1.0.spec test-2.0.spec test-3.0.spec sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*1.0* rpm -qa | grep ^test sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*2.0* rpm -qa | grep ^test sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*3.0* rpm -qa | grep ^test Here is my result: $ sh ./test.sh rpm: no packages given for erase Preparing... ################################# [100%] Updating / installing... 1:test-1.0-1 ################################# [ 33%] 2:test-devel-1.0-1 ################################# [ 67%] 3:test-static-1.0-1 ################################# [100%] test-1.0-1.x86_64 test-devel-1.0-1.x86_64 test-static-1.0-1.x86_64 Preparing... ################################# [100%] Updating / installing... 1:test-2.0-1 ################################# [ 20%] 2:test-devel-2.0-1 ################################# [ 40%] Cleaning up / removing... 3:test-static-1.0-1 ################################# [ 60%] 4:test-devel-1.0-1 ################################# [ 80%] 5:test-1.0-1 ################################# [100%] test-2.0-1.x86_64 test-devel-2.0-1.x86_64 Preparing... ################################# [100%] Updating / installing... 1:test-3.0-1 ################################# [ 20%] 2:test-devel-3.0-1 ################################# [ 40%] 3:test-static-3.0-1 ################################# [ 60%] Cleaning up / removing... 4:test-devel-2.0-1 ################################# [ 80%] 5:test-2.0-1 ################################# [100%] test-devel-3.0-1.x86_64 test-static-3.0-1.x86_64 test-3.0-1.x86_64 And second test on with test-2.0-ver.spec which has changed: --- test-2.0.spec 2017-03-31 18:55:05.986642900 +0100 +++ test-2.0-ver.spec 2017-03-31 18:55:52.877882709 +0100 @@ -3,7 +3,7 @@ Version: 2.0 Release: 1 License: Test -Obsoletes: test-static +Obsoletes: test-static < 2.0-1 %description Test package. Result: $ sh ./test-ver.sh Preparing... ################################# [100%] Updating / installing... 1:test-1.0-1 ################################# [ 33%] 2:test-devel-1.0-1 ################################# [ 67%] 3:test-static-1.0-1 ################################# [100%] test-static-1.0-1.x86_64 test-devel-1.0-1.x86_64 test-1.0-1.x86_64 Preparing... ################################# [100%] Updating / installing... 1:test-2.0-1 ################################# [ 20%] 2:test-devel-2.0-1 ################################# [ 40%] Cleaning up / removing... 3:test-static-1.0-1 ################################# [ 60%] 4:test-devel-1.0-1 ################################# [ 80%] 5:test-1.0-1 ################################# [100%] test-devel-2.0-1.x86_64 test-2.0-1.x86_64 Preparing... ################################# [100%] Updating / installing... 1:test-3.0-1 ################################# [ 20%] 2:test-devel-3.0-1 ################################# [ 40%] 3:test-static-3.0-1 ################################# [ 60%] Cleaning up / removing... 4:test-devel-2.0-1 ################################# [ 80%] 5:test-2.0-1 ################################# [100%] test-3.0-1.x86_64 test-devel-3.0-1.x86_64 test-static-3.0-1.x86_64 As you see result is EXACTLY the same. In attachment you have tar with 4 spec files and two test scripts. It is some possibility that you may be right in some scenario which I still do not understand so please try to change test case to the form when it will start failing presenting exact scenario which is possible to correct/avoid by using versioned Obsoletes. PS ATM I'm ready to bet with at least 1:10 ratio that it is some misunderstanding of some very simple case. So I'm moving my words one step back and putting this case in WIP state asking for exact example implemented in test case. > > BTW Epoch. Using Epoch is only for scenario when it is necessary roll > back > > to earlier version of *the same package* when such package *is > installed*. > > That's not true either. A package doesn't need to be installed at all, and > it doesn't need to be the "same package". In repo metadata highest EVR > wins version comparison. Again, depending on how the package tools and > depsolvers are implemented, you would not even see a package due to its > EVR. Also, there's the scenario of package splits, such as a library > getting released as a separate project with an own versioning scheme, > and Epoch is the only way to handle that, regardless of whether a package > is installed already. > If package is present in rpm database only in form of "Provides: A-<version>-<release>" for resolver effectively it is like such package is really installed. Ergo: it changes nothing. In both cases will be done exactly the same operation o resolving packages dependencies and write new state of installed packages. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
rpm-Obsolete-test.tar.xz
Description: application/xz
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
