Re: build profile proposal: nogir (second try)
As Johannes mentioned earlier in this thread, the first piece of practical
advice on nogir should be: if you don't know that you need to use it,
then perhaps you shouldn't. It's primarily aimed at breaking cycles,
and enabling buildability in lower-level packages during bootstrapping.
(Having said that, at some point I want to convert some not-too-essential
library to this setup, just as a demonstration of how it works in
practice.)
file:///usr/share/doc/gobject-introspection/README.Debian.gz in recent
versions of gobject-introspection has some practical checklists for
making packages with GIR XML and typelibs cross-buildable, and for making
it possible to add the nogir profile. I would say that if you only do
one of those two things to a library, it should be making the library
cross-buildable: that's something that most libraries can benefit from.
On Wed, 24 Jan 2024 at 18:30:02 +0000, Alberto Garcia wrote:
> - Are packages that ship gobject-introspection files supposed to have
> <!nogir> in the relevant build dependencies (gir1.2-*-dev,
> gobject-introspection ?), or is the build profile handling this
> automatically?
If you want to skip a particular build-dependency under this build
profile, you must annotate it with <!nogir>. There is no other way to
skip build-dependencies, and this is true for all build profiles, not
just this one.
The goal of this build profile is more like the other way around,
really. Don't think of it as "packages that ship gobject-introspection
files should implement nogir". Think of it as more like: "packages
that build-depend on gobject-introspection stuff *might* want it to be
possible to turn off that build-dependency: and if they do, the way to
do it without causing FTBFS or breaking dependent packages is to
implement nogir".
For GIR XML and typelibs, I expect that the dependencies that will usually
be marked in this way are gir1.2-*-dev, gobject-introspection, and
libgirepository1.0-dev.
Note that if your package uses gi-docgen to generate documentation,
then that cannot work without enabling introspection, so it might need
something more like:
Build-Depends:
...,
gir1.2-glib-2.0-dev <!nogir> <!nodoc>,
gobject-introspection <!nogir> <!nodoc>,
...,
or even
Build-Depends-Arch:
...,
gir1.2-glib-2.0-dev <!nogir>,
gobject-introspection <!nogir>,
...,
Build-Depends-Indep:
...,
gi-docgen <!nodoc>,
gir1.2-glib-2.0-dev <!nodoc>,
gobject-introspection <!nodoc>,
...,
> - Packages using dh_install may have a line with usr/share/gir-1.0 in
> their debian/libfoo-dev.install. This will fail if the .gir files
> are not generated. What's the recommended way to handle this?
If your GIR XML has been split into a separate gir1.2-foo-0-dev binary
package (see other discussions in this thread), then this isn't a concern
because you can turn off that entire binary package with
Build-Profiles: <!nogir>.
Or, if you're using this build profile in the mode where it changes the
contents of the libfoo-dev binary package (which is non-ideal, but avoids
needing to go through NEW), then there isn't really a recommended way,
but dh-exec is probably the least-bad way.
smcv
Reply to: