On Wed, Apr 17, 2024 at 11:28:53AM +0200, Fabio Valentini wrote: > On Wed, Apr 17, 2024, 08:45 Tim Landscheidt <t...@tim-landscheidt.de> wrote: > > > Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > > > > > […] > > > > >> - 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. > > > > Quick 'n' dirty: Have two binaries, unconditionally call > > add-determinism-python for *.pyc files, either from > > add-determinism or the BRP macro (which essentially should > > be called when %__brp_python_bytecompile is called?), rely > > on the packager to build-require add-determinism-python or > > require that from python3-devel (the missing binary should > > fail the build otherwise). > > > Something like this could be even made automatic. > > - split Python-specific functionality into a separate binary and subpackage > of add-determinism > - add only add-determinism to the default buildroot > - add "Requires: (add-determinism-python if python3)" to add-determinism > > That way the pyc processing functionality would only be pulled in iff > python3 is already getting installed by something else.
Thanks to everyone who made suggestions. A variant of the above is implemented in https://src.fedoraproject.org/rpms/rust-add-determinism/pull-request/1: We' install either add-determinism or add-determinism-nopython. (The two packages provide the same files and declare Conflicts with each other). The appropriate variant will be pulled in via rich dependencies. (The arrangement is a bit different than what is described above, i.e. one or the other binary is installed, because of some low-level implementation needs: - I don't want to spawn a separate "handler" for each type of cleanup. Right now, the different handlers don't process files of the same type, so it doesn't matter much, but such cases can easily occur, for example a .pyc file stored in a .jar, or more realistically, a .html javadoc file embedded in a .jar file. If it's all in a single process, it's fairly easy to arrange how this should be sequenced. - The multi-worker mode is now implemented by spawning N workers, and each worker accepts all file types. This makes the distribution of jobs trivial, we always have one coordinator and N workers. But if we had workers of different types, we'd suddenly need to figure out answers to questions like: how many workers of each type to spawn, e.g. does this particular package have both .jar and .a files, etc. It's much better to avoid this. - Right now the discovery which handlers are used is made once, in the first binary that is called. If it cannot initialize some type of handler (right now mainly only the pyc handler, if python cannot be initialized or marshalparser cannot be imported, but some other handlers have checks on allowed $SOURCE_DATE_EPOCH values), a warning is printed and the handler is skipped. The workers are then initialized with an explicit handler list, and if any of the specified handlers doesn't initialize, this becomes a hard error. Overall, we get warnings just once, and every unexpected failure is an error. If initialization of handlers was moved down, things would become noisier and less tight.) This approach solves the problem and is fairly simple and should be robust. If if turns out to be problematic we can always switch to some different solution in the future. Zbyszek P.S. https://github.com/keszybz/add-determinism/pull/5 was merged, which cuts down on unneeded features in dependencies. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
