On Mon, 17 Jul 2023 at 08:57:51 +0000, Holger Levsen wrote:
> On Sun, Jul 16, 2023 at 11:41:36AM +0100, Simon McVittie wrote:
> > On Sun, 16 Jul 2023 at 00:03:00 +0200, Adam Borowski wrote:
> > > due to Build-Depends
> > > being inadequate (per the Policy, B-D-Indep are _not_ necessarily
> > > installed)
> >
> > For completeness, B-D-Arch are not guaranteed to be installed during
> > clean either.
>
> I wonder what's the point of B-D-Arch And B-D-Indep then?
The point is the same as it always was: primarily to exclude large
dependencies from a `dpkg-buildpackage -B` build chroot (like the official
buildd for each architecture) if they are only needed when building
Architecture: all packages such as documentation, and secondarily to
exclude large dependencies from a `dpkg-buildpackage -A` build chroot
(like the official "all" buildd) if they are only needed when building
Architecture: any packages.
B-D-I are required/guaranteed to be installed for builds that will run
`debian/rules build-indep`, and B-D-A for builds that will run
`debian/rules build-arch`. What Adam has been exercising for this MBF
are builds that will do neither, but only build the source package
(`dpkg-buildpackage -S`). This is a somewhat common thing to want to do
if you do all your builds in a chroot, container, VM or remote machine:
you start from an unpacked source directory or git clone, and you want
to build binary packages "over there", which in many cases requires
giving sbuild etc. a .dsc to work with, but you do not necessarily have
all of the "heavier" dependencies on the local development system where
you will convert the source directory into a .dsc.
You can move tools, libraries etc. from B-D to B-D-A or B-D-I as
appropriate, *if* they are not needed by `debian/rules clean`. In
practice this is usually the case for most "large" build-dependencies.
For instance, if you have documentation built with Doxygen, LaTeX
or other large frameworks, it's usually OK for those tools to be in
Build-Depends-Indep only; or if you have a GTK GUI and you've taken
steps to avoid building it in Architecture: all builds, it's probably
OK for GTK to be in Build-Depends-Arch only.
One common failure mode is that if your source package only builds
Architecture: all packages, it's tempting to move debhelper from
Build-Depends to Build-Depends-Indep, but that's incorrect for the
reasons that Adam raised here (because debhelper is needed during clean).
smcv
