Bug#1061133: libsoup3: Build profiles don't actually work

[Simon McVittie]

On Fri, 19 Jan 2024 at 01:17:36 +0100, John Paul Adrian Glaubitz wrote:
> I was just trying to bootstrap libsoup3 for sh4 using build profiles.
> 
> Unfortunately, that doesn't work since it seems that specifying multiple
> build profiles for a build dependency means that the build dependency is
> removed only if all of the specified profiles are activated.

It can work either way. You can either write

    dep <!nocheck> <!noinsttest>

or
    dep <!nocheck !noinsttest>

and they mean different things. I seem to have a blind spot for this
and can never remember which way round they are without looking it up,
but one of them means "require dep if (!nocheck) && (!noinsttest)"
and the other means "require dep if (!nocheck) || (!noinsttest)".
Each of them makes sense for some packages and some build profiles.

> Thus, in order to strip "libapache2-mod-php" from the build dependencies,
> one has to pass "--profile=nocheck,noinsttest" to sbuild, otherwise the
> libapache2-mod-php build dependency is still pulled in.

That sounds familiar, I think maybe I added that (in libsoup2.4, before
the packaging was forked for libsoup3).

If it's written this way round, it's probably because the build system
will refuse to enable the test suite (either to be run at build-time
or to be installed for later use by autopkgtest) if it doesn't detect
libapache2-mod-php? A lot of GNOME and GNOME-adjacent packages use the
same test executables for build-time and as-installed testing, so it does
often make sense to require a build-dependency if
(!nocheck) || (!noinsttest) - even if you are not going to run build-time
tests, in the absence of noinsttest the package still needs to compile
them, in order to populate the -tests package for later use.

If that's the case, then yes, to bootstrap it you will have to disable
both of those profiles, not just nocheck, and that's probably not a
bug. glib2.0 and dbus have a circular dependency on each other that
works like this, because each wants to use the other in its test suite,
and the way to disable it is to use both build profiles.

> This, however, means that that the "nocheck" profile has to be there to
> boostreap libsoup3 which deactivates "libgnutls28-dev" which makes the
> build fail since this build dependency is mandatory.

*That* sounds like the real bug here. In what way does it fail?

>From a quick look at libsoup3, it seems like it might only need
GNUTLS for part of the test suite, and therefore needs to pass
-Dpkcs11_tests=disabled to meson via dh_auto_configure (overriding
-Dauto_features=enabled) whenever both of these profiles are disabled?

debian/rules in dbus has an example of altering configure options if
both build-time and as-installed tests are disabled, if that helps.

    smcv