Bug#890834: gtk+2.0: Add build profiles to skip flavors and packages

[Simon McVittie]

Control: tags -1 + moreinfo

On Mon, 19 Feb 2018 at 17:30:33 +0100, Javier Serrano Polo wrote:
> Please consider adding the following build profiles:

What goal(s) are you aiming to achieve by requesting this? They might
be better solved some other way.

>       * noudeb: Skip udeb flavor and packages.

That one makes sense for speeding up test-builds and builds in derivatives
that don't use udebs (as long as we *have* udebs, which means until d-i
moves to GTK+ 3); but given gtk+2.0's activity level, that isn't going
to save anyone a whole lot of time.

>       * pkg/gtk+2.0/nogir: Skip gir1.2-gtk-2.0.

The namespace for source-package-defined build profiles is
pkg.some-source.foo, not pkg/some-source/foo.

Unfortunately, a nogir build-profile is either mostly useless (because
it fails to avoid the gobject-introspection build-dependency, which
would still be needed to generate the .gir file in the -dev package);
or incompatible with the design principle that build-profiles do not
change the functionality provided by a Debian package name (because the
.gir file is in the current -dev package); or very intrusive (because
it would require splitting the -dev package).

If there is a build profile with no GIR metadata, it should be done with
the cooperation of the gobject-introspection maintainers, possibly making
changes to the gobject-introspection mini-policy to make it work better.

>       * pkg/gtk+2.0/noexamples: Skip @EXAMPLES_PKG at .

Why? Which build-dependencies can be discarded if this is done? How much
build time does it save?

>       * pkg/gtk+2.0/nopixbuf: Skip @PIXBUF_PKG at .

Why? Which build-dependencies can be discarded if this is done? How much
build time does it save?

>       * pkg/gtk+2.0/nostatic: Skip static flavor and packages, the
>         latter being libgtk$(APIVER)-static-dev and libgail-static-dev.

Those packages don't exist. If you are asking the GTK maintainers to
split them out, that's an intrusive change.

To not break consumers of the package (by not breaking the current
"contract" that libgtk2.0-dev provides enough for both static and dynamic
linking), the part that is split out would have to be the headers and
the dynamic library symlink. Again, that's an intrusive change.

Please explain what your goal is here? With that context, there might be
an alternative that achieves your goal better.

Thanks,
    smcv