[RFC][PATCH 0/1][all] clean up shlibs:Depends warnings

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC][PATCH 0/1][all] clean up shlibs:Depends warnings

Kamal Mostafa-2
Our kernel builds (all?) emit a handful of warnings like:

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

for those packages {image, modules, modules-extra} which don't have any shared
library dependencies*.  I propose that we clean up those warnings by simply
removing those references from the control file stub.

It makes sense to do so only if we can state that those packages could never
have shared library dependencies anyway -- which I think is true.

Any thoughts about applying this to bionic, and a similar delta to all the
rest?

 -Kamal

*I discovered that the similar variable misc:Depends gets set to an empty
string when there are no "misc" dependencies (so it does not yield any annoying
warning).  But sadly shlibs:Depends does not get set at all when there are no
shilbs dependencies (so we get the warning about 'unknown').

---

Kamal Mostafa (1):
  UBUNTU: [Packaging] do not use ${shlibs:Depends} for image or modules

 debian.master/control.d/flavour-control.stub | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

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

Kamal Mostafa-2
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 <[hidden email]>
---
 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
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

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

Thadeu Lima de Souza Cascardo-3
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 <[hidden email]>
> ---

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
> [hidden email]
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

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

Kamal Mostafa-2
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 <[hidden email]>
> > ---
>
> 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

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team