Olaf Hering wrote:

Am Wed, 14 Feb 2018 13:04:14 +0100 schrieb Olaf Hering :

...

How is Leap 15.0 supposed to replace packages that existed in previous Leap versions?

Even openQA fails, according to bug#1069773. I can not reach the referenced openQA host with the logfile, but I'm sure that bug is also about the fact that python-lockfile-0.10.2 from Leap 42 is newer than the variant from Leap 15.

The lp150 prefix was introduced in the hope to avoid such issues in the future. The problem basically are packages that get version updated in maintenance. Since normally all OBS projects have independent checkin- and rebuild counters, it may happen that an old release ends up with higher counters than the new one. For example, the 42.3 PyYAML maintenance update to 3.12 already has release 10.1, whereas in 15.0 it has 1.6. So even without the lp150 prefix the Leap 15 package would be older. In the past we could only solve that to some degree by manually injecting updated counters into the OBS backend. That is annoying and only works until the release. So in the future (assuming that we stick with the versioning scheme for a while ;-) Leap 15.1 will get a lp151 prefix, Leap 16.0 lp160 and so on. So far so good. Back to python which hit a corner case that didn't exist in this large scale so far. Now a package Foo gets split up in Foo2 and Foo3. Foo is considered obsolete by Foo2. If both old and new package have the same version and release counters aren't incremental, the auto generated Obsoletes tag in Foo2 won't match though. Therefore on zypper dup the old package stays and leads to a file conflict with the new one. There's a way to tell zypper dup to consider packages obsolete and uninstall them if possible though. Special markers in the openSUSE-release package (weakremover). Those entries are generated by a script ("droplist generator"). However, so far it didn't look at the update repos of previous releases. Therefore it didn't detect a case like the PyYAML one and didn't generate weakremover entries for it. Fixing that is on TODO¹. There are still two catches though. Firstly, if for some reason, eg. a 3rd party package still requires an obsolete package, the old one would still not be uninstalled on zypper dup. That is actually a feature and makes sense for shared library packages. In the python case it lead to file conflicts unfortunately. Secondly, the droplist generator can update openSUSE-release only until the release of Leap 15.0, so maintenance has to be extra careful to not introduce such update problems afterwards. So I hope that sheds some light on the situation. Suggestions are welcome if anyone has better ideas how to handle that of course. cu Ludwig [1] https://github.com/openSUSE/osc-plugin-factory/issues/1396 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org