May 2025 - CRUX - lists.crux.nu

Lots of useless python3 dependency piling up
by Steffen Nurpmeso 06 May '25

06 May '25

Hello. I have interrupted downloads (it is only "port-up.sh -qd" here, which resolves all dependencies), because by accident i was looking, and suddenly the entire Unicode CLDR data was being downloaded. I understand that few people do the ports, and that things like mesa etc have exploding needs for dependencies. But for opt/libxkbcommon i then see a python3-jinja2 dependency, and that wants python3-babel python3-markupsafe python3-wheel and that goes on, but already -babel wants the entire CLDR. Now i tried, *without* jinja2, to build opt/libxkbcommon exactly as via Pkgfile, and that is meson setup build libxkbcommon-xkbcommon-1.9.0 -D enable-wayland=false -D enable-bash-completion=false --prefix=/usr --libexecdir=/usr/lib --wrap-mode nodownload -D b_lto=true -D b_pie=true -D enable-docs=false plus $ meson compile -C build -j 4 INFO: autodetecting backend as ninja INFO: calculating backend command to run: /usr/bin/ninja -C /tmp/x/build -j 4 ninja: Entering directory `/tmp/x/build' [354/354] Linking target bench-x11 plus $ DESTDIR=.xx meson install -C build and, maybe much to my surprise, it simply works. As far as i can tell. I have no idea of meson, but that interested me a bit, and i saw meson.build:python = pymod.find_installation('python3', modules: ['jinja2'], required: false) and that plain seems to say that jinja2 is *not* required, and that gives the bitter taste of someone having the desire to install dozens of mega packages on people's boxes for no reason i understand. It would be *very* nice if not each and every package needs to become overlayed to avoid this immense stacking up of python3 subpackages. Ciao, and a nice Sunday i wish you all!! P.S.: unless you need it to keep on running, the argument to "mode" in the below is only 0755, not the entire string. I have overlayed it, but if you consider the code quality of the CRUX scripts and package system in the past, and compare it with that, it is hard to imagine new users and developers come over. if ! /bin/mountpoint -q /run ; then /bin/mount -n -t tmpfs -o mode="0755,nosuid,nodev,exec" tmpfs /run || { printf "$(BOLD "$(RED)")" "[ERROR]"; exit 1; } fi --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

2 2

ports/opt (3.8): [notify] python3-wheel: do not force a bytecode level, read message
by crux＠crux.nu 05 May '25

05 May '25

Commit hash: a96c9627397ac65c1d257be3c591bc16b45a30e8 Author: Tim Biermann <tbier(a)posteo.de> Date: Mon May 05 07:06:13 2025 UTC+02:00 URL: https://git.crux.nu/ports/opt/commit/a96c9627397ac65c1d257be3c591bc16b45a30… Commit message: [notify] python3-wheel: do not force a bytecode level, read message installer will compile bytecode level 0 and 1 by default.[1] Forcing it to compile level 2 will overwrite the default, not providing level 0 and 1 entirely. This is a problem since pythons runtime might compile level 0 and 1 bytecode the first time it loads a module [2] which leads to files not tracked by pkgutils db. Removing a package with those symptoms will leave these files behind, which might trigger undesired behavior, like triggering certain tests while the cause is not even installed.[3,4] To fix this, the following solution is proposed: - run a script like pkg-not [5]: pkg-not /usr/lib/python3.12/site-packages - rebuild affected ports with a forced overwrite of existing files: prt-get update -fr --aargs="-f" python3-someaffectedport This commit message stands for all following python related commits. [1]: https://installer.pypa.io/en/stable/cli/installer/ [2]: https://docs.python.org/3/faq/programming.html#id72 [3]: https://lists.crux.nu/archives/list/crux@lists.crux.nu/thread/ZIYNRJQCJ6KAB… [4]: https://github.com/xkbcommon/libxkbcommon/blob/7df431ac4d0d36639876318a4c69… [5]: https://git.crux.nu/tools/prt-utils/issues/1

1 0

And a question on python3 module updates
by Steffen Nurpmeso 03 May '25

03 May '25

Hello once more. I only wanted to know whether there is a way to cause automatic python3 module rebuilds after a python3 update. If i do $ prt-get dependent python3 doxygen nftables python3-setuptools python3-flit-core xorg-xcb-proto that isn't it. However, after updating python (only about 30 MB instead of whatever i said last, iirc something over 50, thank you), the mesa compile failed, because python3-pyyaml and then -mako then -markupsafe where no longer usable by the mesa build. I never used pip3 before, but .. i cannot seem to find anything that would be right for the task there. Now i wonder whether a combination of find /usr/lib/pythonXXXX/site-packages -maxdepth 1 -type d and pkginfo -o would do what i need? (Or can't we skip compilation during build, so that the pycache directories do not exist? Or .. ??) Thanks for any hint, a nice Sunday i wish from Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0