Hi Simon,
Quoting Simon McVittie (2019-09-04 12:09:27)
> I would like to propose this build profile for addition to
> <https://wiki.debian.org/BuildProfileSpec>. I'll add it to the wiki if
> there seems to be rough consensus.
>
> Name: noinsttests
> Changes content of binary packages: No ("C: N" on the wiki)
> Changes set of binary packages: Yes ("S: Y" on the wiki)
> Description:
> Binary packages consisting entirely of automated tests, manual tests,
> example/demo programs and test tools should not be generated.
>
> Typical use:
>
> # dbus requires GLib and Python if we will build either build-time
> # or as-installed tests
> Source: dbus
> Build-Depends:
> ...,
> libglib2.0-dev <!nocheck> <!noinsttests>,
> python3 <!nocheck> <!noinsttests>,
> ...
>
> Package: dbus-tests
> Build-Profiles: <!noinsttests>
> ...
this looks good to me.
> I hope I'm getting the Build-Profiles syntax right here - I think
> it's <!nocheck> <!noinsttests> rather than <!nocheck !noinsttests> but the
> difference between the two always confuses me when combined with
> double-negatives. The intended pseudocode is:
>
> if check || insttests:
> include libglib2.0-dev and python3 in B-D
> else: # (!check) && (!insttests)
> exclude them
The stuff inside <> brackets behaves like the stuff inside [] brackets. It is
OR-ed together. If any of the conditions is true, the whole bracket evaluates
to true. Multiple brackets are AND-ed together in the same way how the much
older architecture lists in [] brackets and version restrictions in () brackets
were AND-ed together. So when you have a dependency like:
Build-Depends: foo (>= 1.0) [amd64 i386] <!nocheck> <cross stage1>
Then all brackets must evaluate to true for the source package to build-depend
on "foo". The last bracket evaluates to true if any of cross or stage1 are
active in the same way how the architecture list evaluates to true if any of
the architectures in the list is equal to the host architecture.
So if you want to say in your example above that you need libglib2.0-dev if and
only if neither the nocheck nor the noinsttest profile are active then you are
correct. What you wrote above can be read as: build depend on libglib2.0-dev if
the following condition is met: nocheck is not active *and* noinsttests is not
active.
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.
> Longer explanation/rationale:
>
> Existence of this profile
> -------------------------
>
> Some upstream packages optionally produce "as-installed" tests, for
> example those participating in the GNOME installed-tests initiative
> (which is a specification for installing automated test programs and data,
> together with metadata describing how to run those tests, conceptually
> similar to Debian's autopkgtest). In Debian we would typically use
> those tests as the basis for an autopkgtest: dbus-tests from src:dbus
> and libglib2.0-tests from src:glib2.0 make good examples of this.
>
> These tests sometimes require extra dependencies at configure time, for
> example extra libraries or a Python interpreter. When bootstrapping, it
> might be useful to disable these dependencies to break cycles, but when a
> new architecture has reached the point where most packages are built, it
> would be useful to rebuild packages with their installed-tests so that the
> autopkgtests can be run.
>
> "nocheck" is unsuitable for this purpose because the specification on
> the wiki says it does not change the contents of binary packages or the
> set of binary packages. For packages that reuse their build-time tests
> as installed-tests (like dbus and a lot of GNOME packages), it is
> necessary to compile the tests in order to install them (perhaps requiring
> extra B-D), even if we do not plan to run them at build-time.
>
> Controls generation of entire packages
> --------------------------------------
>
> Best-practice for build-profiles seems to be that they may enable or
> disable the generation of entire packages, but do not alter the contents
> of any individual package: so your build might or might not produce
> dbus-tests, but if it did produce dbus-tests, you can be sure that it
> is a fully-working version of dbus-tests (and is not missing half its
> usual functionality or test coverage because you were cutting down
> dependencies). This makes "Depends: dbus-tests" meaningful.
>
> This makes the proposed profile "safe" in the sense used in
> https://lists.debian.org/debian-devel/2016/04/msg00381.html, or "C: N"
> in the table on the wiki.
>
> Not solely for as-installed tests
> ---------------------------------
>
> Some source packages bundle their "as-installed" tests into the same
> binary package as other non-essential, test-oriented executables to
> reduce Packages file bloat, for example:
>
> - dbus-tests mostly contains automated as-installed tests, but also has
> manual tests, the dbus-test-tool utility, and a special build of libdbus
> that can be loaded via LD_LIBRARY_PATH for extra debug/logging/assertions
>
> - gtk-3-examples originally contained example executables (or manual tests
> if you prefer to think of them like that), but now contains the
> as-installed tests too
>
> I think this should be allowed, and should not prevent use of the
> noinsttests profile. We shouldn't fill up the Packages file and the NEW
> queue with separate installed-tests, manual tests and examples binary
> packages for no good reason, and if you want to install one of those
> categories, it seems to me that being forced to install the others is
> not onerous.
>
> Some non-GUI libraries do not depend on a graphical toolkit like GTK
> or Qt themselves, but build demo/example programs that do depend on a
> graphical toolkit (for example librsvg used to build a very simple GTK
> SVG viewer, although we've removed that in bullseye, in anticipation of
> its deletion by upstream). For these libraries it would make sense to be
> able to disable that "heavy" dependency. I think these demos/examples
> are more similar to installed-tests than they are different - they
> are intended to be used to prove that the library works correctly, and
> are not normally (build-)depended on, or directly useful to end-users
> (except perhaps when looking for a minimal reproducer for a bug).
As long as this classification is meaningful for packages depending on it I
don't see a problem here. The whole idea of splitting up software into
individual packages is so that we can install components independent from each
other. If there is no use-case where you would want only one part of a package
but not the other then it doesn't make sense to split it up. So following your
rationale I think it's up to the maintainer's discretion of whether some
content looks enough like an as-installed test to fit into such a package.
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.
Just from the dependency graph, all cycles in Debian used to be removable just
by removing around 50-60 edges (dependencies). Of these, many can be solved
either by moving dependencies to Build-Depends-Indep or by cross-compiling
packages. We only need build profiles for the remaining build dependencies but
the number of packages where this is needed will probably not be much larger.
Unfortunately, I cannot show proper numbers for unstable right now because
unstable is currently broken. Since src:matplotlib2 cannot be compiled
(#939303), build-essential cannot be compiled and thus the results which can
usually be found at https://bootstrap.debian.net/botch-native/amd64/stats.html
are not available right now. To find out why matplotlib2 blocks
build-essential, look at the bug or this dot rendering of the dependency graph:
https://bootstrap.debian.net/botch-native/amd64/matplotlib2_2.2.3-6.svg
> The name of the profile
> -----------------------
>
> The "noinsttests" name is inspired by previous discussion (on a bug
> asking for more <!nocheck> in some package, if I remember correctly?),
> and by ginsttest-runner in the gnome-desktop-testing package[1], which
> is a test-runner for GNOME's installed-tests initiative.
>
> If people strongly prefer build profiles to be singular, then "noinsttest"
> would also be fine.
>
> The conventional names for the build-time options that enable/disable
> GNOME installed-tests are --{en,dis}able-installed-tests (Autotools) and
> -Dinstalled_tests={true,false} (Meson), but I think "no-installed-tests"
> or "no-as-installed-tests", or a version of one of those names with
> words run together, would be inconveniently long for a build-profile.
>
> "notests" would be easily confused with "nocheck", which controls whether
> build-time tests are to be run (and presumably takes its name from
> `make check` in the GNU coding standards).
>
> I couldn't think of any other short term that would encompass all the
> automated and manual tests, examples and demos that I want the scope
> of this profile to include. The key facts are that they're test code
> intended to be used in testing and debugging (as opposed to e.g. dbus or
> libglib2.0-bin, which are intended to be used directly "in production"
> by users and/or other programs), and that they're installed (as opposed
> to traditional build-time `make check` tests that don't get packaged).
We called the profiles nocheck and nodoc because of the existing
DEB_BUILD_OPTIONS values of the same name. I think consistency is important and
thus I would go for the singular and otherwise agree with Helmut's assertions.
Thanks!
cheers, josch
Attachment:
signature.asc
Description: signature