Bug 1296875
Summary: | Package in EPEL7 is 0.9.7 when 1.0.10 is now available in Fedora | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Yanis Guenane <yguenane> |
Component: | python-sqlalchemy | Assignee: | Pierre-YvesChibon <pingou> |
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | bretm, infra-sig, kevin, lmacken, mbacovsk, pingou, pj.pandit, shahms, tis |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-01-23 19:10:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Yanis Guenane
2016-01-08 10:14:32 UTC
If that helps : https://koji.fedoraproject.org/koji/taskinfo?taskID=12464688 I do not really know what to do for this. On the one side, EPEL does not like pushing update of major release and going to sqlalchemy 1.0.10 would be. On the other side, sqlalchemy is normally pretty good at backward compatibility. But since I haven't been into the details, I do not know how much this is true between 0.9.7 and 1.0.10. Note: SQLalchemy-utils is more fragile than sqlalchemy itself, so pushing updates of SA-utils to EPEL might become tricky/trickier in the future. I'd be ok pushing 1.0.11 (current) and letting it stay in testing for a while. I think upstream is pretty good about compatibility, so if we ran into something they might well fix it. Read on the changelog page[1] > Please carefully review the sections on behavioral changes for potentially backwards-incompatible changes in behavior. After looking deeper at the changelog I couldn't find any change really backward-incompatible except eventually this one[2] (Second snippet). [1] http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html [2] http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html#postgresql-has-table-now-works-for-temporary-tables ok. I made a scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=12579891 can you do a bit of testing with that, and if it looks ok, I can build and push to testing. Hey Kevin,
> can you do a bit of testing with that, and if it looks ok, I can build and push to testing.
We ran our application with the build you provided and everything is working as expected. I don't mean to use we cover all the features of SA but for our use case it's a go. Thanks for taking care of it.
s/don't mean to use/don't mean to pretend python-sqlalchemy-1.0.11-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c1eb98d18b python-sqlalchemy-1.0.11-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c1eb98d18b python-sqlalchemy-0.9.8-1.el7 is part of rhel so please remove package from epel and block it. Sigh. Right you are. ;( Will get it retired... Strangely, it's in both rhel7-server AND rhel7-server-extras (I sure hope RH keeps them in sync). Anyhow, I have unpushed this update and retired this package in epel7. yguenane: can you re-file your request against the rhel7 version of the package and see if they want to update it there? kevin: will do that. Sorry for the confusion here :( I will be more careful next time. |