Re: Proposed build profile: noinsttests

[Simon McVittie <smcv@debian.org>]

On Thu, 05 Sep 2019 at 07:19:30 +0200, Johannes Schauer wrote:
> I agree that it can be confusing but I think it is just as confusing as any
> other doubly negated boolean expression. It usually helps me to draw the truth
> table when I'm unsure. Your example of <!nocheck !noinsttests> is probably not
> what you meant to express because then the source package would still build
> depend on libglib2.0-dev unless *both* profiles are active.

That's actually what I want. A `make check` with full test coverage
runs tests that require GLib, for which we obviously need to build those
tests first. Building the dbus-tests package requires building (but not
necessarily running) those same tests, so that we can copy them into
debian/tmp. Either way, we need GLib.

So the truth table I want is that dbus build-depends on:

              | !noinsttests    | noinsttests     |
   -----------+-----------------+-----------------+
    !nocheck  | libglib2.0-dev  | libglib2.0-dev  | (so we can build the tests we will run)
   -----------+-----------------+-----------------+
    nocheck   | libglib2.0-dev  | (nothing)       |
   -----------+-----------------+-----------------+
               (so we can build
               the tests we will
               install)

> While we are talking about splitting up packages and thus increasing the size
> of our Packages file, let me also point out, that estimating where it makes
> sense to split a binary package into two for the sake of cutting dependency
> cycles very often not obvious and that splits of existing packages for the sake
> of better bootstrappability should probably not happen without a bootstrapper
> having claimed that a given package causes problems as it is.

Sure, I'm not saying that maintainers of a libfoo-bin package containing
both "useful binaries to depend on" and examples or installed-tests
(like librsvg2bin in buster) should split it just because this profile
exists. (However, if the examples or installed-tests are large or have
significantly "heavier" dependencies, then the package should probably be
split anyway.)

    smcv