We should make a decision about linux-libc-package when constructing
debian/control.
Once debian/control is generated, builders must follow it. In other
words, we should not re-evaluate the do_libc_dev_package variable at
the build time.
Debian kernel commit fdd6dadb4aee ("Use dh_listpackages to determine
which packages to build") [1] introduced the if_package macro.
Import it to consult dh_listpackage to check if linux-libc-package is
listed in debian/control.
UBUNTU: [Packaging] check debian.env to determine do_libc_dev_package
The linux-libc-dev package provides UAPI headers. The Linux kernel
promises backward compatibile API to userspace. That is the reason
why there exists only one linux-lib-dev per series. Its package name
does not contain any ABI number or flavour string since there is no
point in installing multiple instances of linux-lib-dev.
This leads to an obvious conclusion; only the master kernel should
provide linux-libc-dev.
Currently, it is checked at compile-time. If you attempt to build
linux-libc-dev on a non-master kernel, it errors out with
"non-master branch building linux-libc-dev, aborting".
When constructing debian/control, the linux-libc-dev enablement is
determined by do_libc_dev_package, which is set to true if the
'variants' variable contains '--'. This is tricky, and it is difficult
to understand the intention. In fact, do_libc_dev_package is true for
most kernels except linux-unstable. Derivative kernels disable
linux-libc-dev by removing linux-libc-dev.stub.
This commits adopts a simpler logic; enable linux-libc-dev if
debian/debian.env contains DEBIAN=debian.master.
Please note this commit changes the behaviour of linux-unstable.
linux-unstable previously disabled linux-lib-dev because it defined
variants=-wip, but it is enabled now. It should not be a big deal
since we do not publish linux-unstable.
Signed-off-by: Masahiro Yamada <email address hidden>
Acked-by: Dimitri John Ledkov <email address hidden>
Signed-off-by: Dimitri John Ledkov <email address hidden>
