[RFC,1/1,bionic] UBUNTU: [Packaging] do not use ${shlibs:Depends} for image or modules

Resolve build warnings for the main image and modules packages which
have no shared lib dependencies and hence get no generated
${shlibs:Depends} variable, resulting in:

    dpkg-gencontrol: warning: Depends field of package PACKAGE:
        unknown substitution variable ${shlibs:Depends}

for PACKAGE's:

    linux-image-unsigned-4.15.0-24-generic
    linux-image-unsigned-4.15.0-24-lowlatency
    linux-modules-4.15.0-24-generic
    linux-modules-4.15.0-24-lowlatency
    linux-modules-extra-4.15.0-24-generic

Signed-off-by: Kamal Mostafa <kamal@canonical.com>
---
 debian.master/control.d/flavour-control.stub | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

On Tue, Jul 10, 2018 at 12:17:39PM -0700, Kamal Mostafa wrote:
> Resolve build warnings for the main image and modules packages which
> have no shared lib dependencies and hence get no generated
> ${shlibs:Depends} variable, resulting in:
> 
>     dpkg-gencontrol: warning: Depends field of package PACKAGE:
>         unknown substitution variable ${shlibs:Depends}
> 
> for PACKAGE's:
> 
>     linux-image-unsigned-4.15.0-24-generic
>     linux-image-unsigned-4.15.0-24-lowlatency
>     linux-modules-4.15.0-24-generic
>     linux-modules-4.15.0-24-lowlatency
>     linux-modules-extra-4.15.0-24-generic
> 
> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
> ---

We use dh_shlibdeps instead of calling dpkg-shlibdeps directly. That means it's
looking for the installed ELF files. Up to compat 10, it was either looking for
executable files or matching names (.so and a few others). After compat 11, it
looks for ELF headers, but that won't match the modules, as they are not
dynamic ELF executables or ELF shared objects (it matches only those ELF
types).

On the other hand, we still call dh_shlibdeps for those packages that don't
need it. So, I would complement this change with removing those calls.

In the investigation, it was interesting finding out that the headers package
contains some executables from the scripts directory, some of which are dynamic
linked, causing the package to depend on those. So, we need to take care do
keep shlibs for that, not only the other userspace tools.

Cascardo.

>  debian.master/control.d/flavour-control.stub | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/debian.master/control.d/flavour-control.stub b/debian.master/control.d/flavour-control.stub
> index 918b41a..2cc4711 100644
> --- a/debian.master/control.d/flavour-control.stub
> +++ b/debian.master/control.d/flavour-control.stub
> @@ -27,7 +27,7 @@ Architecture: ARCH
>  Section: kernel
>  Priority: optional
>  Provides: linux-image, fuse-module, aufs-dkms, =PROVIDES=${linux:rprovides}
> -Depends: ${misc:Depends}, ${shlibs:Depends}, kmod, linux-base (>= 4.5ubuntu1~16.04.1), linux-modules-PKGVER-ABINUM-FLAVOUR
> +Depends: ${misc:Depends}, kmod, linux-base (>= 4.5ubuntu1~16.04.1), linux-modules-PKGVER-ABINUM-FLAVOUR
>  Recommends: BOOTLOADER, initramfs-tools | linux-initramfs-tool
>  Breaks: flash-kernel (<< 3.90ubuntu2) [arm64 armhf], s390-tools (<< 2.3.0-0ubuntu3) [s390x]
>  Conflicts: linux-image=SIGN-PEER-PKG=-PKGVER-ABINUM-FLAVOUR
> @@ -49,7 +49,7 @@ Build-Profiles: <!stage1>
>  Architecture: ARCH
>  Section: kernel
>  Priority: optional
> -Depends: ${misc:Depends}, ${shlibs:Depends}
> +Depends: ${misc:Depends}
>  Description: Linux kernel extra modules for version PKGVER on DESC
>   Contains the corresponding System.map file, the modules built by the
>   packager, and scripts that try to ensure that the system is not left in an
> @@ -68,7 +68,7 @@ Build-Profiles: <!stage1>
>  Architecture: ARCH
>  Section: kernel
>  Priority: optional
> -Depends: ${misc:Depends}, ${shlibs:Depends}, linux-image-PKGVER-ABINUM-FLAVOUR | linux-image-unsigned-PKGVER-ABINUM-FLAVOUR, crda | wireless-crda
> +Depends: ${misc:Depends}, linux-image-PKGVER-ABINUM-FLAVOUR | linux-image-unsigned-PKGVER-ABINUM-FLAVOUR, crda | wireless-crda
>  Description: Linux kernel extra modules for version PKGVER on DESC
>   This package contains the Linux kernel extra modules for version PKGVER on
>   DESC.
> -- 
> 2.7.4
> 
> 
> -- 
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Fri, Jul 13, 2018 at 05:24:47PM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Tue, Jul 10, 2018 at 12:17:39PM -0700, Kamal Mostafa wrote:
> > Resolve build warnings for the main image and modules packages which
> > have no shared lib dependencies and hence get no generated
> > ${shlibs:Depends} variable, resulting in:
> > 
> >     dpkg-gencontrol: warning: Depends field of package PACKAGE:
> >         unknown substitution variable ${shlibs:Depends}
> > 
> > for PACKAGE's:
> > 
> >     linux-image-unsigned-4.15.0-24-generic
> >     linux-image-unsigned-4.15.0-24-lowlatency
> >     linux-modules-4.15.0-24-generic
> >     linux-modules-4.15.0-24-lowlatency
> >     linux-modules-extra-4.15.0-24-generic
> > 
> > Signed-off-by: Kamal Mostafa <kamal@canonical.com>
> > ---
> 
> We use dh_shlibdeps instead of calling dpkg-shlibdeps directly. That means it's
> looking for the installed ELF files. Up to compat 10, it was either looking for
> executable files or matching names (.so and a few others). After compat 11, it
> looks for ELF headers, but that won't match the modules, as they are not
> dynamic ELF executables or ELF shared objects (it matches only those ELF
> types).
> 
> On the other hand, we still call dh_shlibdeps for those packages that don't
> need it. So, I would complement this change with removing those calls.

My thinking is that it would be actually be preferable to leave those
dh_shlibdeps calls in place, because then we could in the future
possibly add some logic someplace to actually verify that
${shlibs:Depends} remains unset for those packages where we expect it to
find no shared libs dependencies.

Maybe we should implement that verification logic along with this
change, and I'm happy to work on that if that idea makes sense.

> 
> In the investigation, it was interesting finding out that the headers
> package contains some executables from the scripts directory, some of
> which are dynamic linked, causing the package to depend on those. So,
> we need to take care do keep shlibs for that, not only the other
> userspace tools.

Yes, I found that "interesting" too, and was going to complain about
that subsequent to this.

It seems wrong to me that there should be any executables in a "headers"
package, and it actually caused me some grief recently when trying to
shoehorn a bionic-targeted kernel onto a Xenial box.  (I was unable to
install the bionic headers package that I needed because Xenial doesn't
supply the dependent version of libssl1.1, iirc).

Could we just move the executables in headers into the tools pkg instead?

 -Kamal