build-details.json should be installed to different locations for nondebug/debug builds and have distinct base_interpreter values
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- Python
- Sterne
- 77.2k
- Forks
- 35.9k
- PR-Merge-Kennzahlen
- PR-Kennzahlen ausstehend
Beschreibung
Bug report
Bug description:
In Fedora, we build Python in 4 variants: debug, optimized, freethreading-debug and freethreading. For all of them builds the base_interpreter value stored in the file build-details.json is the same:
"base_interpreter": "/usr/bin/python3.14",
I suspect it should reflect the build type and contain the applicable suffix(es): d, t, td.
Because of this line, when we run Python's test suite on an installed python3-debug, the test fails, as you can see e.g. here: https://artifacts.dev.testing-farm.io/0ac8ab69-ed5f-4602-9c01-8c13293aa9b6/
test_base_interpreter (test.test_build_details.CPythonBuildDetailsTests.test_base_interpreter) ... FAIL
======================================================================
FAIL: test_base_interpreter (test.test_build_details.CPythonBuildDetailsTests.test_base_interpreter)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/usr/lib64/python3.14/test/test_build_details.py", line 124, in test_base_interpreter
self.assertEqual(os.path.realpath(value), os.path.realpath(sys.executable))
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: '/usr/bin/python3.14' != '/usr/bin/python3.14d'
- /usr/bin/python3.14
+ /usr/bin/python3.14d
? +
Another issue is that in both cases, the debug and non-debug files are installed to the same location, resulting in a single rewritten file. In case of our sequential build of 4 Pythons, we end up with just two files. Should they be stored in distinct locations for each build instead?
CPython versions tested on:
3.14
Operating systems tested on:
Linux
Linked PRs
- gh-142256
- gh-142269
- gh-150098
- gh-150414
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne mit test/test_build_details.py, insbesondere test_base_interpreter, und reproduziere den im Issue beschriebenen installierten Debug-vs.-Non-Debug-Fehler. Verfolge, wie build-details.json für die vier Varianten generiert und installiert wird; fertig ist es, wenn jede installierte Datei den zutreffenden base_interpreter-Wert und unterschiedliche Speicherorte hat und der Test erfolgreich ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- python
- Bereich
- build-system
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 25/100