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
