Skip to content

build-details.json should be installed to different locations for nondebug/debug builds and have distinct base_interpreter values #131372

Open
Open
build-details.json should be installed to different locations for nondebug/debug builds and have distinct base_interpreter values#131372
Labels
buildThe build process and cross-buildtopic-installationtype-bugAn unexpected behavior, bug, or error

Description

@befeleme
befeleme
opened on Mar 17, 2025

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

Activity

  1. befeleme
    added
    type-bugAn unexpected behavior, bug, or error
    on Mar 17, 2025

  2. hugovk commented on Mar 17, 2025

    @hugovk
    hugovk
    on Mar 17, 2025
    Member

    cc @FFY00

  3. picnixz
    added
    buildThe build process and cross-build
    topic-installation
    on Mar 17, 2025

  4. FFY00 commented on Apr 29, 2025

    @FFY00
    FFY00
    on Apr 29, 2025
    Member

    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?

    Just ship the file for the main/default interpreter, I guess? We probably shouldn't install the file in altinstall, and better document expectations for scenarios like yours.

  5. vstinner commented on Dec 4, 2025

    @vstinner
    vstinner
    on Dec 4, 2025
    Member

    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?

    We may do something similar to sysconfigdata filename like including ABI tags. Example:

    • build-details.json: default Python
    • build-details_d.json: debug build
    • etc.
  6. FFY00
    added 5 commits that reference this issue on Dec 4, 2025

    pythonGH-131372: only install build-details.json in the main install

    9fefc6e

    pythonGH-131372: only install build-details.json in the main install

    4719fe3

    Merge branch 'main' into pythongh-131372

    ecea32b

    GH-131372: only install build-details.json in the main install (#142269)

    bcb6cbd

    gh-131372: Include LDVERSION and EXE in base_interpreter value (#142256)

    c0d0f4b

  7. stefanor commented on May 10, 2026

    @stefanor
    stefanor
    on May 10, 2026
    Contributor

    FWIW, there is a draft PEP PR to resolve the design: python/peps#4889

  8. stefanor commented on May 20, 2026

    @stefanor
    stefanor
    on May 20, 2026
    Contributor

    #150098 implements a configure flag to allow selecting a more-qualified than just build-details.json filename.

  9. FFY00
    added a commit that references this issue on May 25, 2026

    gh-131372: Configurable build-details.json name (#150098)

    9c23f34
  10. vstinner
    added a commit that references this issue on May 25, 2026

    gh-131372: Fix a typo on "with_build_details_suffix" in configure (#1…

    583cb03

  11. vstinner commented on May 28, 2026

    @vstinner
    vstinner
    on May 28, 2026
    Member

    The "Configurable build-details.json name" change was only merged in the main branch, but the 3.15 is also affected by this issue, no? Should we backport the change to 3.15? (with the typo fix as well)

  12. stefanor commented on May 28, 2026

    @stefanor
    stefanor
    on May 28, 2026
    Contributor

    3.14 and 3.15 include build-details.json. So there is value in backporting that to both.

    For me, the main point of the PR was to have an upstream-blessed name for this file that includes the architecture and necessary tags. That goal is now achieved and without needing a backport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildThe build process and cross-buildtopic-installationtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions