Jan Kundrát wrote: > do you have some examples of distribution maintainers actually doing such > a stupid thing?
I've done it more than once. If the dependency that the latest upstream version wants is not available and will not be made available for whatever reason, reverting the dependency bump is really the only way. And the users will be no worse off than if we had stuck to the old version that did not have the changes I am reverting to begin with. I have already given an example, from when I was still maintaining the core Qt 5 packages in Fedora: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qtbase-opensource-src-5.3.2-old_xkbcommon.patch?id=e26fd4ffda851bfe13d975547e218e16f72ce556 (for Fedora 19, and for Fedora 20 until xkbcommon got updated there). I am not a maintainer of Qt 5 nor KWin in Fedora anymore, but I would still be happy to give assistance with coming up with such a patch IF the maintainers ask me. (I find producing such patches very easy.) But to be clear, all this is hypothetical planning for future releases, and the maintainers may decide to do something different (e.g., to upgrade Plasma/KWin only in a Copr also offering a newer xkbcommon), or xkbcommon might get updated anyway (there is already a build for Fedora 25, it was just not submitted in Bodhi, so I don't know what the plans are there). So, to make it clear, Fedora at this time DOES NOT REVERT any dependency bump in KWin! > In my professional epxerience, the distro maintainers that I have worked > with were reasonable people who invest time into doing valuable QA and > packaging duties. Surely there's no place for "hey, let's go break this > code" as your proposal suggests. What you call "break", I call "make work". It is that or not have the code at all. And the existing old version was already "broken" in the same way. Kevin Kofler
