Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile
Helmut Grohne writes ("Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile"):
> On Thu, Dec 15, 2022 at 11:44:34PM +0000, Ian Jackson wrote:
> > I'm not sure precisely how this feature could (or should) be made
> > available to *all* application packages in a central way. Having
> > tools like debcargo automatically add the profile to the build deps
> > produces a lot of bloat. I'm hoping there is a better way.
>
> I think this becomes the crux of the matter. I see basically two
> distinct ways to move forward:
...
> What are your thoughts on updating Build-Depends?
I think that in packages where the maintainer has deliberately chosen
to support this build profile, the maintainer should annotate the
Build-Depends.
> B
>
> In this case, the profile description should be more clear about the
> intended scope (rust application packages).
Yes.
Is "application package" precisely the right term? It could also
apply to: packages which provide shared objects (eg a .so plugin);
ABI/API libraries (eg trad C libraries whose innards are now rewritten
in Rust); packages which provide an executable that isn't an
application.
The possible scope includes any package whose .deb contains
executables (including possibly WASM, as well as native code) made by
compiling Rust. It might even include packages where Rust is used
only as part of the build system.
One way to describe the exception would be to say something like
(except Rust library packages)
or
(except Rust library packages themselves)
> I also do not see us automating the update to Build-Depends.
I agree but for different reasons to yours. I don't want this done to
every Rust leaf package routinely, which would be the natural end
point of automating this.
> > This could be made easier. Maybe tools like sbuild could have a
> > sepaarate option to disregard build deps matching a wildcard pattern,
> > or something.
>
> The idea is good in principle. Let me do a brief excursion into
> Multi-Arch for comparison. By default, we have an architecture
> constraint on dependencies. It can be lifted either by M-A:foreign on
> the target of the edge or by :any on the source of the edge. A build
> profile is a bit like :any and annotates the source of an edge. Your
> proposed wildcard pattern would be a target annotation for build
> profiles in this analogy while the current profile implementation has no
> way to do such target annotations.
Yes. The information would ideally be centralised: "if you have a
Build-Dependency matching librust-*-dev, disregard it with this
build-profile". So the edges would be "annotated" but implicitly.
Failing that I guesss we could add a general facility of this shape
Disregard-build-depends-with-build-profile: upstream-cargo
a la M-A.
> This idea is also applicable beyond rust. With the nopython build
> profile, we might want to automatically annotate Python dependencies.
> Unfortunately, we are now in a place where a significant portion of
> packages uses Python modules during build (e.g. sphinx) while not
> producing any Python modules or extensions as output. As such, we cannot
> mechanically tell how such a dependency is being used. Maybe a package
> later contains a rust crate that is not shipped, but only used during
> build. In this case, we wouldn't want to annotate the relevant
> dependencies either.
The analogy with "nopython" is rather misleading. (You could have
"norust" too; not sure if that's in the list right now.)
With nopython, we want to *avoid doing the Python things at all*. But
"the Python things" here isn't "all Python things" - it's "certain
Python things that appear in the outputs". So that can't be done as a
blanket exclusion on B-d.
With upstream-cargo, we want to *do all the Rust things, but get them
all from upstream crates.io*. This should affect *every* dependency
on a cargo package (except ones that are within the source package
itself).
So if a package that previously didn't do any Rust things, gains a
Rust crate that is not "shipped" (to /usr/share/cargo/registry), then
this buid profile does become nontrivially applicable. (Of course
this build profile is trivially applicable to packages which don't
involve cargo at all).
The reason why the upstream-cargo profile ought not to be provided for
a Rust library crate is not becuase it's incoherent or wrong in a
narrow sense.
A Rust library crate typically *does* actually run rustc during rules
build, as a check:
https://deb.debian.org/debian/pool/main/r/rust-cxx/rust-cxx_1.0.73-1.dsc
And in principle it is perfectly coherent to say "please build this
source package, but do the check with upstream Rust Dependencies".
But this is not *useful* to support as a build profile. Narrowly,
because you might as well just say "nocheck" and run the "cargo test"
yourself by hand.
But, more relevantly, and broadly: no-one needs to do this. If you
are working on a Rust library, then either (i) you are doing this as
part of work to get the Rust library into Debian, in which case making
some kind of hybrid situation like this is just going to lead to
confusion and pain - you should use the Debian Rust universe, and
build fromk the bottom up; or (ii) you *aren't* trying to use the
Debian Rust ecosystem at all, in which case why are you bothering ?
IOW the reason the build profile isn't applicable to Rust library
source packages is because a Rust library source package produces only
Rust library .debs, but the use case for the build profile is
precisely to use upstream crates instead of Rust library .debs.
> So I think annotating rust Build-Depends has to be a semi-manual task at
> least. Updating dh-cargo or debcargo to automatically adapt its
> behaviour still seems useful though as that reduces the amount of work
> to updating Build-Depends.
Yes.
And, also, having the tooling honour this build-profile allows the
user to bodge the situation, when they want to build a naive
compiled-Rust-code package in another context. *That* could be done
with a DEB_BUILD_OPTION but it doesn't make much sense to have the
same thing both as a (fully-supported, but manually applied) build
profile and a (requires bodging, but universally applicable) build
option.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Reply to: