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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)