Hi, Am 13.12.20 um 09:37 schrieb Matěj Cepl:
Dirk Müller píše v Čt 10. 12. 2020 v 16:42 +0100:
I only seem to receive half of the conversation. Dirk did you send to Matej directly and only he replied back to the list (with two addresses, so I get that message twice)?
One of the packages that I care about for example is eventlet. Now for reasons that I don't fully know we have updated dnspython to 2.x, which is incompatible (this is documented upstream). I tried to fork a dnspython1 package, which was deleted. patches to add dnspython 2.x support were added instead, which did not yet go upstream, and while they passed some of the unittests, it actually caused a lot of pain in real functionality. so effectively it broke eventlet.
Regarding that particular case: dnspython1 is still present in d:l:p. Why was it deleted from Factory (?). You describe a very valid reason to have it: Packages need it for painless functionality. We have more packages in a similar situation: pytest, tornado, Sphinx, etc. We probably need a better guide how to set up the names, prjconf files and Provides/Obsoletes/Conflicts tags so that (in my opinion) ill-advised changes like https://build.opensuse.org/request/show/852863 don't happen.
Now, there were newer releases, and maybe there is a release now that supports the newer dnspython, but lets generalize the concern: every other distribution seems to stick dnspython on the older version if it breaks something major, and we instead have the conversation of "its outdated, needs to be updated".
[...]
I do feel like this was frustrating for both sides, and this example should very clearly demonstrate that there is no value whatsoever to always ship the newest package. I am suggesting to by policy aim for shipping the newest *working* package.
I'd rather state it as: "If there is a stable, working, newer package, provide it" in the sense that TW provides the greatest and latest. But it should go along with "If an outdated package is needed in order not to break something major, provide it as alternative. As long as it does not pose a security risk.
Again, I don't remember repeatedly reverting cmd2, that sounds truly bad, but I ended up making comments in SPEC files in sense "Do not upgrade until you are certain you are not breaking python-foo!". Just above the Version: line. Perhaps, that could help.
That's why we need activated unit tests and at the very latest notice breaking stuff in Staging. Ben