Hi Julian, On Fri, Dec 20, 2024 at 12:21:37PM +0100, Julian Andres Klode wrote: > # norust build profile > > I propose we add a `norust` build profile such that packages > building Rust parts or integrating with Rust parts can > disable those parts.
Thanks for taking this to the appropriate place. > For example, if apt gains sqv support, we can define a > pkg.apt.nosqv buildprofile, but it would be nice to just > use norust too. Contrary to what we earlier chatted on IRC, I am no longer convinced that "norust" is a useful profile name for your use case. If you look at the other language-specific profiles, they're all about bindings into other languages. A common theme applicable to multiple languages is a C library that also provides a Python and Perl extension to interface with. The language is the addon to something that can exist without that language. In case of Rust, it tends to go in reverse. The thing is implemented in Rust and you interface with other ecosystems via various mechanisms - CLI in this case. > The norust profile must NOT be used by packages building > exclusively Rust pieces, that is, it should be possible > to bootstrap a Rust toolchain and package set with the > profile set (and potentially you need externally built > cargo idk). I suggested this restriction for a very different reason. I don't see a reason to want to bootstrap a Rust toolchain with a norust profile set yet. My reason was to avoid excessive churn in lots of Rust libraries where removing Rust removes the reason for existence. In keeping with the spirit of other no$LANG profiles, norust has a place, but it is bindings bolted onto other packages. However, this is not how bindings are typically packaged. Unlike other languages Rust tends to put them into separate crates and package them as separate Debian source packages rendering the utility of a norust profile minimal here. The no$LANG profiles are all (but nogir) marked as "reproducible" profiles. That is, if you enable the profile, you do not expect output artifacts to change (but you expect the set of output artifacts to change). This is very much not how you intend to use norust. Conversely, we would not expect a nopython build profile to skip building documentation generated using sphxindoc. We would not expect a noperl profile to skip generating pod2man documentation. I think your use case warrants a different approach and as a result a different naming pattern. What you are concerned with is availability (being ported) of a software. It's not about whether you can interface with it using that language but about whether you can use anything that uses it. It's a different level of not wanting something. As a result, my preliminary conclusion here is to NACK your request barring further insight. My intuition now is to add a separate concept "unavailable" to the profile naming scheme. Beyond Rust, valgrind, ebpf and llvm are fairly obvious candidates for things you may want to integrate with but that are not universally available on all architectures. > I then propose we inject the > > DEB_BUILD_PROFILES=norust > > in the buildds for the ports architectures that do not have > a rustc. I think this is a separate matter to defining the meaning of the profile. I defer to port maintainers (e.g. Samuel) on this matter but suggest that more work may be needed. > This could be solved by encoding the build profiles in the > dpkg vendor module instead, but it may also be beneficial > to be able to experiment more and have local builds try > to build with everything. Please add detail here. I don't think a change to dpkg is sufficient here. For instance, sbuild would have to somehow discover the per-architecture profiles and apply them to installing Build-Depends. We likely need to update Debian policy here. Helmut
