On Tue, Apr 16, 2024 at 09:42:27AM +0200, Pavel Raiskup wrote: > On sobota 13. dubna 2024 21:04:06, CEST Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Apr 13, 2024 at 01:38:49PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote: > > > > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek > > > > <zbyszek@xxxxxxxxx> wrote: > > > > > > > > > > Yes. But actually I think Rust is the optimal choice here. Writing > > > > > this in Python would be possibly slightly nicer, but we don't want > > > > > to pull the interpreter and packages into the buildroot. Python > > > > > also has the problem (challenge?) that it needs to be bootstrapped > > > > > once per year. The less packages are involved in the bootstrap, the > > > > > easier it is. And if the brp was written in Python, we'd need to > > > > > deal with that, and it would probably increase the number of builds > > > > > which are done without the cleanup. Having this as an indepedent > > > > > binary avoids some of the issues with bootstrap. > > > > > > > > I think Rust *would* be a good choice here ... > > > > BUT add-determinism uses pyo3 to link to CPython, so it pulls in > > > > python3-libs anyway. > > > > So you get the downsides of pulling in Python without the upsides of > > > > using Rust ... > > > > > > Yes, it currently pulls in python3-libs as a dependency, but not the > > > rest of the Python stack. Ideally, the dependency on python3-libs will > > > become optional, and we'll use it if found at runtime if found and > > > ignore otherwise. (Anything that creates pyc files will have python > > > installed, so it's fine if the pyc handler only works if there.) > > > How to best do this is something that needs to be figured out… > > > > https://github.com/keszybz/add-determinism/pull/1 makes the dependency > > on libpython optional. One option would be to compile the binary > > twice, and use rich dependencies to install the heavyweight one if > > python3 is installed. If somebody has a better approach, I'm all ears. > > I do not claim these are better approaches, but you could: > > - you could consider using tooling "from host", not "from chroot" > (adding a dependency to Mock seems just fine then) Hmm, how would that work? We call mock, which calls systemd-nspawn, which runs rpmbuild, and the build env is completely isolated from the host. > - use dynamic buildrequires to detect what plugins are needed My problem is that the binary is linked to the libpython3.12.so shared library… The detection part is easy, the hard part is how to have the binary work when the shared lib is not installed. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
