build-details.json should be installed to different locations for nondebug/debug builds and have distinct base_interpreter values
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
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
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
test/test_build_details.py、特に test_base_interpreter から始め、issue に記載されたインストール済みの debug-versus-nondebug の失敗を再現します。4 つのバリアントについて build-details.json がどのように生成され、インストールされるかを追跡します; 各インストール済みファイルに該当する base_interpreter の値と異なる場所があり、テストが通れば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- build-system
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 25/100