Description of problem: I did an update today which failed with the following error: nothing provides python3.10dist(pillow) >= 9 needed by python3-reportlab-3.6.10.fc35.x86_64 I ran dnf list all and get: python3-reportlab.x86_64 3.6.2-2.fc35 @updates python3-reportlab.x86_64 3.6.10-1.fc35 updates I can install python3-reportlab but I am immediately notified of an update which fails as noted. I reported this against component python3.10 because there is no component python3-reportlab. Version-Release number of selected component (if applicable): 3.6.1-1.fc35 How reproducible: Always Steps to Reproduce: 1.Install python3-reportlab 2.Try to install the update 3. Actual results: nothing provides python3.10dist(pillow) >= 9 needed by python3-reportlab-3.6.10.fc35.x86_64 Expected results: The update installs Additional info: I ran dnf repoquery --deplist python3-reportlab to find out the dependencies, but it produced no output. So where does python3.10dist(pillow) come from? Also the version that got installed on my F35 VM: python3-reportlab.x86_64 3.6.1-1.fc35 The update was done via dnfdragora, doing sudo dnf -y update --best --allowerasing --skip-broken python3-reportlab results in: Error: Problem: cannot install the best update candidate for package python3-reportlab-3.6.2-2.fc35.x86_64 - problem with installed package python3-reportlab-3.6.2-2.fc35.x86_64 - nothing provides python3.10dist(pillow) >= 9 needed by python3-reportlab-3.6.10-1.fc35.x86_64
Can we update python-pillow to 9 in f35? Otherwise, i must process the f35 package and return to previous release of python-reportlab
Hmm I usually don't push major version upgrades to released Fedora versions. Looking at the Pillow 9 changelog [1], I see that some deprecated functions were removed. This could potentially impact existing code. [1] https://github.com/python-pillow/Pillow/releases/tag/9.0.0
Another way would be to revert the following on Fedora 35 only: https://hg.reportlab.com/hg-public/reportlab/rev/94016d4f9dcc
My question is if there is a version 3.6.10-1.fc35 of reportlab why is this not installed? Why not remove version 3.6.2-2.fc35, and install 3.6.10-1.fc35?
(In reply to pgaltieri from comment #4) > My question is if there is a version 3.6.10-1.fc35 of reportlab why is this > not installed? Why not remove version 3.6.2-2.fc35, and install > 3.6.10-1.fc35? Because dependency is broken, as you already saw. > nothing provides python3.10dist(pillow) >= 9 needed by python3-reportlab-3.6.10-1.fc35.x86_64 python3-reportlab needs fixing, which is currently discussed here.
The upstream commit does not explain why it needs pillow >= 9. I guess the commit simplifies a use of pillow by dropping a support for older pillow versions. A question is why reportlab-3.6.10 tests pass with pillow-8.3.2 we have in F35. Maybe the minimal version is not 9 and the metadata in setup.py are overstrict. Maybe the tests do not check that code path at all. Question is why setup.py or the spec file does not qualify a build-dependency on pillow with a minimal version. If you are not brave enough to patch and keep using reportlab-3.6.10 with pillow-8.3.2, then you will need to downgrade reportlab which is done by reverting the package version back to 3.6.8, reverting ./sources file content, and adding Epoch: 1 tag into the spec file. You will also need to increase Release number to have a unique build NVR in Koji. Also if aspire for a smooth upgrade path between Fedora releases, you will need add the Epoch into higher Fedoras (> 35) to ensure a monotonic NEVR.
Just some bystander comments, expanding on what Petr mentioned: upstream change seems to be: https://hg.reportlab.com/hg-public/reportlab/rev/94016d4f9dcc That change bumps the required version of pillow from 4.0 -> 9.0. From what I see this change does multiple things: - bump the minimal pillow version to 9.0 - removing a fallback which could also use PIL ("import Image") or pillow < 1.0 - remove fallback code in the library which would be triggered if pillow is not installed (haveImages = None). The last part makes up most of the changed lines as far as I can see. The change makes a lot of sense as all of that fallback code was pretty useless. pillow was required already in setup.py (even if it was just 4.0). By removing the fallback they can get rid of a lot of "if haveImages". In my personal opinion this commit should have been 3 commits: 1. removing the fallback code with haveImages 2. removing the "import Image" fallback (could be folded into #1 if you don't like tiny commits) 3. bumping the pillow version with some comment why this is necessary Based on my reading + experience with pillow I think: - pillow 8.3 and 9.0 should not be that different and I think reportlab is still using the exact same pillow API as before, just without useless fallback code - if the tests are passing with pillow 8.5 this indicates my reading is correct - you could try to contact upstream (including patch author Claude Paroz claude at 2xlibre.net) to verify this - then you could just lower the runtime requirement - try to add something in %check which ensures the all declared reportlab requirements are met at least at build time (or build some qa checks - never used these)
*** Bug 2097989 has been marked as a duplicate of this bug. ***
> The upstream commit does not explain why it needs pillow >= 9. I guess the commit simplifies a use of pillow by dropping a support for older pillow versions. Quoting a reply in the Reportlab mailing list (https://pairlist2.pair.net/pipermail/reportlab-users/2022-June/012278.html) " AFAIK, the minimal pillow version is mostly there because older versions are affected by several security issues. If the distro is backporting security issues to old pillow versions, then you should be able to "manually" downgrade the pillow requirement without impact on ReportLab. But Robin might give some more enlightment to this question. " Now, i guess that best (and simplest) choice is this: in Fedora 35 --> pushing python-reportlab-3.6.9 epoch 1 in Fedora 36+ --> pushing python-reportlab-3.6.10+ epoch 2
*** Bug 2098345 has been marked as a duplicate of this bug. ***
Of course you can do the epoch thing but based on my code reading + upstream answer I think it should be safe just to patch the version requirement + bump the release number (3.6.10-2.fc35). Basically reportlab upstream is trying to solve some "distribution-level" tasks (ensuring that the user gets all security updates even for dependencies) and the Python ecosystem does not really provide good mechanisms to do that so they are just bumping the version requirement. I've seen this in several projects and I still think this is the wrong approach but well... Anyway I add Fedora-specific patches in these cases and never encountered a problem. I find hust increasing the release number to be less error-prone but of course this is your call. If you like I can submit a pull request so you can check the possible approaches side-by-side though it would be nice to solve this soon-ish.
> If you like I can submit a pull request so you can check the possible approaches side-by-side though it would be nice to solve this soon-ish. Yes, please.
Please see https://src.fedoraproject.org/rpms/python-reportlab/pull-request/2
FEDORA-2022-9d594bad46 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9d594bad46
FEDORA-2022-9d594bad46 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-9d594bad46` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9d594bad46 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Heads up, hplip upgrade was failing with this dependency issue: hplip x86_64 3.22.4-1.fc35 updates 18 M hplip-common x86_64 3.22.4-1.fc35 updates 73 k hplip-gui x86_64 3.22.4-1.fc35 updates 1.3 M hplip-libs x86_64 3.22.4-1.fc35 updates 164 k . . . Skipping packages with broken dependencies: python3-reportlab x86_64 3.6.10-1.fc35 updates 2.9 M ----- I upgraded using FEDORA-2022-9d594bad46 and this broken dependency went away. hplip now works after downloading the required plugin for the printer. Will provide feedback as requested. Thank you!
*** Bug 2101464 has been marked as a duplicate of this bug. ***
FEDORA-2022-9d594bad46 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Did an update and the fixed package installed without errors. python3-reportlab.x86_64 3.6.10-1.fc35.1 It's OK to close this bug.
Closing this.