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

[Kamal Mostafa]

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 at 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