Hi Julian, On Sat, Dec 28, 2024 at 08:57:18AM +0100, Helmut Grohne wrote: > As a result, my preliminary conclusion here is to NACK your request > barring further insight.
I pondered your use case in my head a bit more and am less and less convinced that build profiles are the right hammer for your screw. Earlier, I suggested copying the valgrind-if-available approach and you took issue with that. Unfortunately, that is now lost to IRC history. Maybe you could summarize it here? I also did not flesh out how I would transfer valgrind-if-available to the problem at hand. The better model may be mysql/mariadb where we now have src:mysql-defaults. Similarly, we could have a gpgv-defaults source package building a default-gpgv package whose dependency depends on the architecture. I remember that you took issue with encoding the availability of Rust into a source package and there definitely is a cost to this approach if it is needed for more packages. At a later point, we may reconsider a profile based approach and use it in the proposed gpgv-defaults package. The upshot is that this works today without any changes to our buildd infrastructure. From an apt point of view, you end up having a build dependency on default-gpgv. At build time, you need to branch on what implementation actually got installed. In the event that you move forward with this, I'd still appreciate a pkg.apt.nosqv build profile that reverts back to gnupg for all architectures, because I don't see a good way to add Rust to the architecture cross bootstrap due to unresolvable disagreement with llvm toolchain maintainers. It could also be a profile of gpgv-defaults. I'd really like us to benefit from Rust implementations in more areas, but the current way its requirements are packaged pose road blocks. Helmut
