On Monday, April 8, 2019 12:11:55 PM CEST Tomas Chvatal wrote: Hi Tomas,
I'm specifically interested why we are not able to name the subunit subpackage based on the standard naming, which would have prevented the situation in the first place. Well that is for Matej to answer. I didn't control how the packages are named I didn't even notice the pypi name is python-subunit and not just subunit.
Ok, assuming there is no reply then I guess we're good with going back to following standard practices and treat this as a bug. I'll be happy to "fix" that then, just wanted to avoid misunderstanding policies and then being educated about it after I did the work.
Well your submission is still screwed up, so it is "fixing" rather than really fixing the issue is it not? https://build.opensuse.org/request/show/692028
you're referring to the "provides"? yeah, I noticed that this was just the tip of the iceberg. I meanwhile added a fixed package as an overlay to the CI.
0.12 is required by openstack, so I can't just downgrade it. How do the others actually pull the openstack in if they do ship only the 0.11? Also note that the 0.12 behaves differently between py2 and py3 so I wonder how that works too if you check the code.
"others" typically have a openstack specific repository of packages that is in itself consistent and matching what openstack expects.
What exactly is the problem with just using "subunit.iso8601" as upstream does ? if there is a problem, can we just fix it upstream first? what happened to the "not modify stuff downstream" policy? Well there also is a policy of not using bundled libraries if it can be avoided.
This is not a bundled library, its a vendored library. I mean with that that it is installed as subunit.iso8601. I totally agree with you that installing the iso8601 module from subunit would be wrong (this would be "bundled"). If it is vendored inside a module, we can still try to untangle it (as we tried with requests for several releases). I would hope that we do learn from the requests mess though: * almost every "version update of requests" introduced new severe regressions because the unvendoring was done downstream, and every downstream did it slightly differently, annoying the hell out of upstream because every downstream introduced a slightly different set of bugs * upstream eventually gave in and did the unvendoring themselves. As such I would consider a vendored library an engagement with upstream to figure out a proper way of doing that rather than replacing stuff with symlinks in the packages (and then adding patches to fix it up (and then adding patches to drop the tests that no longer pass (and then add a patch that breaks it for everyone that didn't get noticed because the tests that would notice it got dropped))).
So I am perfectly fine if you prune all the patches and make it bundled for me it was just faster to revert the iso8601 to older version when I got told by DimStar that my staging won't get in unless this gets fixed.
Yeah, I don't really like how really really super central packages are just being version downgraded to "get my stuff in" without even doing high level cross checking with the maintainers of "osc whatdependson XXX" but that is for another rant some other time. For now I would really like to get the subunit package in a working state first. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org