Draft solution: Keep track with python-setuptools and create our own pip-repository inside repo.hyperbola.info, modify pypi to point to our local pip-repository and finally (soft-)fork pip to enable python-build and python-installer.

Advantage within is a way forward, disadvantage is more amount of work to keep track for separated repositories and file-management for the tarballs to be downloaded at build-time.

WARNING: This is neither an ideal nor a very safe way and just a first draft. This solution includes a possible violation of free software distribution guidelines and furthermore also a spot making packages later on part of the system users have no real influence and / or transparency about.

On that matter of using more than once programming-language at the same software-project: So-called "modern" implementations have a severe tendency to add just more than one language for building. So besides C and / or C++, Python, Perl, Rust and many more. Adding such complexity-level makes the whole project more complicated to audit, understand and ready for "easy" modifications. Users on the search to become their own developers get more blocks in the way and mandatory  efforts are being blocked out technical and social. Then resulting also within more points to look on solutions being clearly no solution likewise LLM / machine-learning to overcome complexity - like an illusion running into more needs and dependencies. So on the statement of minimalism Hyperbola is making this should be at all costs kept out.

High critical (build-infrastructure)

gcc: In need for a clear research as newer releases include Rust-definitions for a later inclusion of an own Rust-compiler, until unclear how dependencies should be resolved at build-time for Rust-projects later version of gcc (beyond version 12.x) need further evaluation

python: Newer releases are surely possible, but since version 3.9 there is no further support for libressl exclusive provided and need patching, furthermore based packages on python are using python-installer and python-build with clear inclusion of pip, this collides with Hyperbola's essential notes (quote from blacklisting: https://git.hyperbola.info:50100/softwa … klist.txt)

meson: Newer releases added an own package-repository for referencing at build-time (for reference: https://mesonbuild.com/Wrapdb-projects.html), as Hyperbola has already a pakage-manager and for clear security-reasonings this should be completely excluded and is therefore in need for research if even possible to be complete removed, otherwise this package is another one in need to be frozen

cmake: Newer releases will start adding an own package-management, for reference: https://www.phoronix.com/news/CMake-Tig … -Integrate

Medium critical (dependencies, frameworks and libraries)

git: With upcoming release of version 3.0 announced to make rust mandatory for build-infrastructure (see here: https://lore.kernel.org/git/20250904-b4 … @pks.im/), as long as there is no finalized reference-implementation being clear free from trademark- and copyright-issues there is no way around that

librsvg: Is in need of rust for building, therefore Hyperbola preserved the last working version without rust as librsvg-legacy which then resulted also as example for later on added so-called "legacy-packages" kept frozen in a concrete version-number

Low critical (applications)

inkscape: With version 1.1 added pre-defined templates for non-free services, therefore adapting non-free services on a social level and making a statement that their acceptance including their violation of user-rights and -freedoms is acceptable on different scale (in need for a decision of kept or handled different)

Uncritical (kept solely working)