Re: The noudeb build profile and dh-only rules files
On Mon, 08 Jul 2019 at 19:23:39 +0100, Colin Watson wrote:
> On Mon, Jul 08, 2019 at 01:25:32PM -0400, Theodore Ts'o wrote:
> > How important is noudeb, and why is defined in the first place?
>
> I'm afraid memory has failed me in terms of why it was defined, other
> than perhaps performance for people doing rapid iteration.
I think I was one of the originators of noudeb, and more rapid iteration
was certainly my main motivation. In packages like dbus and glib2.0,
noudeb can avoid doing a full second build (or even a third build in
the case of dbus) when doing test-builds, and the udebs from a test-build
aren't usually going to be tested or used anyway.
If widely adopted it's also a convenient way to speed up multiple
packages' builds by skipping udebs globally, in distributions whose
maintainers know that they aren't going to use debian-installer at all,
like some of the Debian derivatives I've worked on in my job.
If your package doesn't do an extra build for udebs, or just has short
compile times in general, then noudeb will have little impact on either
of those goals and is unimportant.
dbus definitely has to do a separate build pass for udebs, because the
"full-fat" version has dependencies that don't exist as udebs:
libdbus -> libsystemd, and dbus -> libaudit/libapparmor. (Having said
that, dbus' udebs are only there for the benefit of AT-SPI, but according
to #929132 AT-SPI in the graphical installer hasn't been implemented in
the 5+ years since it was requested, so maybe they can be dropped.)
I thought glib2.0 was in the same situation, but libmount-udeb does
exist, so it might actually be possible to stop doing the secondary build
for glib2.0 in bullseye. glib2.0 is used in the graphical installer,
where GTK, fonts and graphics probably swamp the size saving from doing
a reduced-functionality glib2.0 build.
> If the udeb stanzas in debian/control have "Build-Profiles: <!noudeb>",
> then debhelper will honour that when deciding which packages to build,
> so yes, anything built into debhelper should just work.
Treating udebs as implicitly having Build-Profiles: <!noudeb> might be a
reasonable feature request for debhelper, but I don't think it implements
that right now. Like everything else in udebs, it might be too niche to
be considered a worthwhile investment of effort.
> Even after simplification, you may well have remaining code in
> debian/rules that refers to udebs, or an extra udeb build pass, or
> something else that dh wouldn't be able to handle by itself. In such
> cases, you can wrap that code in a dh_listpackages check of the kind
> described in
> https://wiki.debian.org/BuildProfileSpec#The_Build-Profiles_field.
You might find that dbus and glib2.0 are useful examples for this.
smcv
Reply to: