Bug 2164207
| Summary: | Update of python3-ptyprocess fails because file in new version conflicts with file from old version | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
| Component: | python-ptyprocess | Assignee: | Orion Poplawski <orion> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | daniel.mach, igor.raits, jmracek, jrohel, kevin, mblaha, mhroncok, mikhail.v.gavrilov, orion, packaging-team-maint, pkratoch, pmatilai, python-packagers-sig, rpm-software-management, tomspur, vascom2, vmukhame |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-01-26 16:43:26 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
Adam Williamson
2023-01-24 18:49:14 UTC
Note, upgrading from python3-ptyprocess-0.6.0-17.fc37.noarch (the current stable version in F37) to python3-ptyprocess-0.7.0-2.fc38 works fine. It only seems to be upgrading from python3-ptyprocess-0.7.0-1.fc38 to python3-ptyprocess-0.7.0-2.fc38 that's problematic. I think this might be the old 'replace a directory with a file and rpm can't deal with it'. ;( Well, possibly, but -2 is just from the mass rebuild; it has no changes from -1 beyond the NVR bump. And also, as per above, the problem doesn't happen when updating from the older 0.6.0-17.fc37 build in F37... Yes, it's the rpm directory replacement problem. What is baffling here is that why does a simple rebuild cause the egg-info to go from a directory to a single file? The single file egg-info is what the deprecated Python distutils produced, the setuptools replacement creates the newer directory variant. So the change in 1 -> 2 is going in the wrong direction due to some external change as the spec itself did not change except for bump release. There's a lot of water under the bridge between these two builds, but it does explain the difference: https://kojipkgs.fedoraproject.org//packages/python-ptyprocess/0.7.0/1.fc38/data/logs/noarch/root.log and https://kojipkgs.fedoraproject.org//packages/python-ptyprocess/0.7.0/2.fc38/data/logs/noarch/root.log In 1.fc38 python3-setuptools gets pulled in, in 2.fc38 it doesn't. And so the egg-info format goes backwards. Reassining to python-ptyprocess because there's absolutely nothing *dnf* can do about this, but python-ptyprocess can be fixed by adding "BuildRequires: python3-setuptools". Not having it will likely cause a build failure with Python 3.12 where distutils has been dropped. But something external had that dependency and now doesn't, so there's a chance there are other packages affected by the same thing. Miro, any ideas? Ah, thanks for catching that - interesting. It's something in the dep chain of either python3-pytest or python3-devel that previously required setuptools but no longer does; I'm not sure what, yet. I've sent a build - https://koji.fedoraproject.org/koji/taskinfo?taskID=96654321 - that should fix this. Instead of adding a dep on setuptools, which upstream doesn't really want to use, I switched to using the more modern pyproject macros, that for this project wind up building it with flit (its preferred build system), and producing a dist-info dir instead of an egg-info file or dir. Packages that are buildable with both distutils and setuptools all have a tendency to this problem. See also https://fedoraproject.org/wiki/Changes/Reduce_dependencies_on_python3-setuptools The mitigations are: [CHAOTIC NEUTRAL] Add BuildRequires for python3-setuptools and hope for the directory to happen. or: [TRUE NEUTRAL] Add BuildRequires for python3-setuptools and put a trailing slash to the .egg-info directory in %files to make the package FTBFS if it is a regular file to assert this never happens again. or: [LAWFUL GOOD] (as Adam did, thank you) Build with modern pyproject macros (and hence have .dist-info directory and no .egg-info -- .dist-info can never be a file). or: [CHAOTIC EVIL] Add a test in %check that assets .egg-info is a file. This breaks with Python 3.12. Note that with the distutils removal from Python 3.12 we will finally get rid of this problem. --------------- As far as why this happened: > It's something in the dep chain of either python3-pytest or python3-devel that previously required setuptools but no longer does; I'm not sure what, yet. It is python3-py. See $ repoquery -q --repo=rawhide --requires python3-pytest (python3.11dist(pluggy) < 2~~ with python3.11dist(pluggy) >= 0.12) /usr/bin/python3 python(abi) = 3.11 python3.11dist(attrs) >= 19.2 python3.11dist(iniconfig) python3.11dist(packaging) Vs $ repoquery -q --repo=fedora --releasever=37 --requires python3-pytest (python3.11dist(pluggy) < 2~~ with python3.11dist(pluggy) >= 0.12) /usr/bin/python3 python(abi) = 3.11 python3.11dist(attrs) >= 19.2 python3.11dist(iniconfig) python3.11dist(packaging) python3.11dist(py) >= 1.8.2 <--------- HERE python3.11dist(tomli) >= 1 $ repoquery -q --repo=fedora --releasever=37 --requires python3-py python(abi) = 3.11 python3-setuptools <--------- HERE (possibly redundant) I have one remark to https://src.fedoraproject.org/rpms/python-ptyprocess/c/4e815433c5bad754f66cb97da95c27a34f4c7ea4?branch=rawhide The Python packaging guidelines require packages to have: BuildRequires: python3-devel They don't even mention: BuildRequires: pyproject-rpm-macros Technically, both options work (and both options will produce the same set of BuildRequires at the end) but BuildRequiring the macros instead of python3-devel is a bit non-standard. Oh, yeah, you're right. I cargo-culted that over from my fedfind spec, which I think I based on an earlier draft of the guidelines or something. I'll adjust it. *** Bug 2164693 has been marked as a duplicate of this bug. *** I verified the -3 build does fix this. Thanks again to Panu and Miro. *** Bug 2164697 has been marked as a duplicate of this bug. *** |