Description of problem: borgmatic package is missing at least 2 runtime dependencies when installed in CentOS 7.5.1804: * ruamel.yaml<=0.15 (which is available in EPEL: python34-ruamel-yaml-0.13.14-1.el7.x86_64) * pykwalify>=1.6.0 (which is not available) Version-Release number of selected component (if applicable): version 1.1.15 release 2.el7 How reproducible: Always Steps to Reproduce: 1. yum install borgmatic 2. borgmatic Actual results: ``` Traceback (most recent call last): File "/usr/bin/borgmatic", line 5, in <module> from pkg_resources import load_entry_point File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 3140, in <module> @_call_aside File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 3126, in _call_aside f(*args, **kwargs) File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 3153, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 640, in _build_master ws.require(__requires__) File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 941, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3.4/site-packages/pkg_resources/__init__.py", line 828, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'ruamel.yaml<=0.15' distribution was not found and is required by borgmatic ``` Expected results: No import error Additional info: The source RPM at dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/b/borgmatic-1.1.15-2.el7.src.rpm indicates those dependencies are included in Fedora, but only as build deps, so I believe the package requires fixing for Fedora as well.
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.