Re: Proposed `cargo-upstream` dpkg-buildpackage etc. build profile
Hi Ian,
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:
A
Do not annotate Build-Depends. We've seen a number of reasons for not
doing it, but the most significant are bloating sources and that it is
quite mechanical work while editing debian/control is usually manual.
In this case, a build profile is the wrong tool for the job. The value
for draw from build profiles precisely comes from formalizing their
effects in debian/control. If your profile skips this step, then it is
not the right tool.
> But even without modifying the build dependencies, it is a lot easier
> to cause a build to run without the stated build deps being satisfied,
> than it is to do violence to the package build system.
I concur, but in this case, it can be a DEB_BUILD_OPTIONS or some other
variable.
Admittedly, I think that the value of this feature significantly reduces
without annotating Build-Depends, because you can no longer just use
sbuild or pbuilder. The ease of use suffers.
B
In this case, the profile description should be more clear about the
intended scope (rust application packages).
I also do not see us automating the update to Build-Depends.
> 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.
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.
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.
What are your thoughts on updating Build-Depends?
Helmut
Reply to: