Bug 1655324
Summary: | borgmatic package is missing dependencies in CentOS 7 | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Julien Nicoulaud <julien.nicoulaud> |
Component: | borgmatic | Assignee: | Felix Kaechele <felix> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | bugzilla-redhat, bugzilla-redhat, dev, d-seats, felix, jelledejong, julien.nicoulaud, lav |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-06-23 20:49:32 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: | |||
Bug Depends On: | 1808090, 1763554 | ||
Bug Blocks: |
Description
Julien Nicoulaud
2018-12-02 19:10:25 UTC
I can confirm this bug on latest centos 7 versions, can somebody take a look at the bug and fix the dependencies? Confirm bug still present in Fedora 29 and 30, with impossible-to-meet dependencies of python3-ruamel-yaml # dnf install borgmatic [...] Error: Problem: conflicting requests - nothing provides python3.7dist(ruamel.yaml) <= 0.15 needed by borgmatic-1.2.0-3.fc30.x86_64 First of all: should I open a separate ticket for the Fedora aspect of this? (issue definitely related but different platform than initially reported) Now for some digging: (tell me if misguided!) Available version of package in F30: # dnf info python3-ruamel-yaml Name : python3-ruamel-yaml Version : 0.15.41 Release : 4.fc30 Architecture : x86_64 Size : 1.2 M Source : python-ruamel-yaml-0.15.41-4.fc30.src.rpm [...] Borgmatic upstream test-requirements.txt file[1] states `ruamel.yaml>0.15.0,<0.16.0` is ok, so the package available in Fedora30 should be ok to use, which makes me think it's the Fedora repackaging that's pinning down ruamel.yaml unnecesarily. Reading the package spec of Fedora[2] doesn't reveal any specific package version pinning (but I've never worked with Fedora's package spec system, might be wrong there). Out of curiosity, I started digging for why ruamel-yaml >0.15.0 could be bad, and came up with package description warning of API deprecation[3], but a discussion on borgmatic tracker[4] which concluded the 0.15.0 pinning requirement was obsolete and a commit in master[5] removed it. --- Summarizing: Dependency seems pinned in borgmatic's Fedora packaging (but I couldn't see explicitly where that is done in package spec), and the pinning seems unnecessary since upstream tests with a similar version Fedora has available in package repos. If someone can help me find the place where that dep is pinned, we can try changing the spec, build the pkg, giving it a go, and hopefully fix this wonderful package for everyone. [1]: https://projects.torsion.org/witten/borgmatic/src/branch/master/test_requirements.txt#L23 [2]: https://apps.fedoraproject.org/packages/borgmatic/sources/spec/ [3]: https://pypi.org/project/ruamel.yaml/ [4]: https://projects.torsion.org/witten/borgmatic/issues/38 [5]: https://projects.torsion.org/witten/borgmatic/commit/d29c7956bc17ef106483c17ef5d256077463f571 (In reply to Jb from comment #2) > Summarizing: Dependency seems pinned in borgmatic's Fedora packaging (but I > couldn't see explicitly where that is done in package spec), and the pinning > seems unnecessary since upstream tests with a similar version Fedora has > available in package repos. Hah, I was so wrong. I downloaded the impossible-to-install RPM file from dnf and it is the upstream python package's requirements.txt[1] that has the "pinning", causing dnf to fail installation. Turns out the restriction on package version was loosened in 1.2.1[2], one patch release after 1.2.0 that fedora is trying to ship. So I'll try bumping the required version of package in fedora's packaging system[3]. Funny enough, this change would be in line with the "upgrade the package version" bug[4], even though we'd just go to 1.2.1 instead of latest=1.3.4 [1]: In borgmatic-1.2.0-3.fc30.x86_64.rpm the file is usr/lib/python3.7/site-packages/borgmatic-1.2.0-py3.7.egg-info/requires.txt which states ruamel.yaml<=0.15 [2]: version 1.2.1 shipped this change https://projects.torsion.org/witten/borgmatic/commit/d29c7956bc17ef106483c17ef5d256077463f571 [3]: https://src.fedoraproject.org/rpms/borgmatic/blob/master/f/sources [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1592160 Unfortunately, I am not getting any response from the maintainer of pykwalify on the blocker bug. Meanwhile, feel free to use my COPR which has current builds + dependencies for EPEL7 and EPEL8. python36-ruamel-yaml will need updating to. I am hoping the recent CVE filed for it provides enough incentive to bump the version in EPEL 7. I no longer have an intention to maintain borgmatic for EPEL7 (and EPEL8) as the dependencies available in EL7 are simply too old to sensibly support borgmatic going forward. EL8 is also missing a few dependencies that I don't intend to also maintain. I have, however, just pushed borgmatic for EPEL9: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-32f5a695d0 If anyone is interested in picking this back up feel free to reopen this bug. |