On Monday, April 8, 2019 10:27:05 AM CEST Tomas Chvatal wrote:
are a number of things depending on the pypi name to be correct, so now again all of our python stack is completely unresolveable.
We were matching up what other distros do to track it from the main subunit package as they needed to be all shipped at once:
I'm okay with making "subunit" the main package and providing the proper tools, that was indeed a long standing problem, so it is good to get it addressed.
grep name= subunit-1.3.0/setup.py
so, I would like to understand why we were renaming the package away from a standard name to a one-off naming
There are still the provides for python2-bla and python3-bla it seems we accidentally missed to provide also python-bla to keep it working on Leaps.
So the explanation is that we switched to a one-off naming because we match up what other distros were doing? Is this the new naming policy?
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.
This was being processed for 5 months in staging projects for Tumbleweed. It is kinda weird no cloud integration checks spotted it.
Because in the staging projects python-python-subunit still existed, and no problem was ever occurring from happening. The rename to python-subunit was the one that caused the issue.
Also, the Cloud stagings are working against Leap, not tumbleweed.
Also I see you took upon yourself 'fixing' it over the weekend in the develprj where you messed it even more when you removed the patches and didn't add unittest2 dependency now.
its a build dependency only, and currently pulled in via testtools. if you need it to be listed explictely, that can be done.
Thanks for the quotes around 'fixing' btw, I highly appreciate that ;)
Also the python3-iso8601 is not broken, they just absolutely changed api between version 0.11 and 0.12 where no distribution apart from us ever shipped the 0.12 so you can fix it by downgrading:
0.12 is required by openstack, so I can't just downgrade it.
Yes, thanks for this other breakage, I wanted to keep the mail to one problem at a time though.
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?