[PATCH] builddeb: introduce variables for control-file customization

[PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

The debian packages coming out of "make *deb-pkg" lack some critical
information in the control-files e.g. the "Depends:" field. If one
tries to install a fresh system with such a "linux-image" debootstrap or
multistrap might try to install the kernel before its deps and the
package hooks will fail.

Different debian-based distros use different values for the missing
fields. And the values differ between distro versions as well. So
hardcoding of e.g. "Depends" is not possible.

This patch introduces an option variable for every debian package built
by builddeb. That allows advanced users to pass additional arguments to
"dpkg-gencontrol" e.g. to set "Depends". All the new variables are
optional.

for example:
make \
	KDEB_OPTS_IMAGE=\
"-DDepends='initramfs-tools | linux-initramfs-tool, kmod, linux-base'" \
	KDEB_OPTS_LIBC_HEADERS="-DMaintainer='root@machine' -v42" \
	bindeb-pkg

Signed-off-by: Henning Schild <henning.schild@siemens.com>
Signed-off-by: Konrad Schwarz <konrad.schwarz@siemens.com>
---
 scripts/package/builddeb | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index b4f0f2b3f8d2..037e722bbd8f 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -13,7 +13,10 @@
 set -e
 
 create_package() {
-	local pname="$1" pdir="$2"
+	local pname="$1"
+	shift
+	local pdir="$1"
+	shift
 
 	mkdir -m 755 -p "$pdir/DEBIAN"
 	mkdir -p "$pdir/usr/share/doc/$pname"
@@ -30,7 +33,8 @@ create_package() {
 	chmod -R a+rX "$pdir"
 
 	# Create the package
-	dpkg-gencontrol $forcearch -Vkernel:debarch="${debarch}" -p$pname -P"$pdir"
+	dpkg-gencontrol $forcearch -Vkernel:debarch="${debarch}" -p$pname \
+		-P"$pdir" "$@"
 	dpkg --build "$pdir" ..
 }
 
@@ -353,11 +357,13 @@ Description: Linux support headers for userspace development
 EOF
 
 if [ "$ARCH" != "um" ]; then
-	create_package "$kernel_headers_packagename" "$kernel_headers_dir"
-	create_package "$libc_headers_packagename" "$libc_headers_dir"
+	eval 'create_package "$kernel_headers_packagename" \
+		"$kernel_headers_dir"' "$KDEB_OPTS_IMAGE_HEADERS"
+	eval 'create_package "$libc_headers_packagename" \
+		"$libc_headers_dir"' "$KDEB_OPTS_LIBC_HEADERS"
 fi
 
-create_package "$packagename" "$tmpdir"
+eval 'create_package "$packagename" "$tmpdir"' "$KDEB_OPTS_IMAGE"
 
 if [ -n "$BUILD_DEBUG" ] ; then
 	# Build debug package
@@ -381,7 +387,8 @@ Description: Linux kernel debugging symbols for $version
  all the necessary debug symbols for the kernel and its modules.
 EOF
 
-	create_package "$dbg_packagename" "$dbg_dir"
+	eval 'create_package "$dbg_packagename" "$dbg_dir" \
+		' "$KDEB_OPTS_IMAGE_DBG"
 fi
 
 if [ "x$1" = "xdeb-pkg" ]
-- 
2.13.6

Re: [PATCH] builddeb: introduce variables for control-file customization

[Jim Davis]

On Mon, Nov 27, 2017 at 9:13 AM, Henning Schild
<henning.schild@siemens.com> wrote:
> The debian packages coming out of "make *deb-pkg" lack some critical
> information in the control-files e.g. the "Depends:" field. If one
> tries to install a fresh system with such a "linux-image" debootstrap or
> multistrap might try to install the kernel before its deps and the
> package hooks will fail.

Has that shown up in practice?  The builddeb script goes back some years now...

> +       eval 'create_package "$kernel_headers_packagename" \
> +               "$kernel_headers_dir"' "$KDEB_OPTS_IMAGE_HEADERS"

eval in a shell script with arbitrary input can lead to shenanigans like

make bindeb-pkg KDEB_OPTS_IMAGE_HEADERS="; echo All your base"

and other potentially nastier things.  Probably not an issue for a
typical kernel developer sitting in front of his or her laptop, but if
I ran a big automated unattended build farm I might prefer a non-eval
alternative.

-- 
Jim

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Mon, 27 Nov 2017 16:57:58 -0700
schrieb Jim Davis <jim.epost@gmail.com>:

> On Mon, Nov 27, 2017 at 9:13 AM, Henning Schild
> <henning.schild@siemens.com> wrote:
> > The debian packages coming out of "make *deb-pkg" lack some critical
> > information in the control-files e.g. the "Depends:" field. If one
> > tries to install a fresh system with such a "linux-image"
> > debootstrap or multistrap might try to install the kernel before
> > its deps and the package hooks will fail.  
> 
> Has that shown up in practice?  The builddeb script goes back some
> years now...

Yes it has, i came across this issue with a multistrap-based installer.
The kernel got picked as one of the first packages. Without explicit
deps i can only assume that deboostrap should be affected as well.
Maybe it processes the package-tree in another order and happens to
work by chance.
My guess is that most people use the builddeb script to install
additional kernels on a running system, so the missing deps never
showed.

That said, the patch would allow for much more customization than just
adding deps. But others might want to customize the other fields as
well.

> > +       eval 'create_package "$kernel_headers_packagename" \
> > +               "$kernel_headers_dir"' "$KDEB_OPTS_IMAGE_HEADERS"  
> 
> eval in a shell script with arbitrary input can lead to shenanigans
> like
> 
> make bindeb-pkg KDEB_OPTS_IMAGE_HEADERS="; echo All your base"
> 
> and other potentially nastier things.  Probably not an issue for a
> typical kernel developer sitting in front of his or her laptop, but if
> I ran a big automated unattended build farm I might prefer a non-eval
> alternative.

True. As you said, that might not be an issue for most people. Let us
discuss the general approach first. If we agree on applying such a
patch and others also raise this issue we might find an implementation
without the eval.
That is a first shot that can handle the kinds of strings one might
want to pass to dpkg-gencontrol. (spaces, pipes and multiple options).

Henning

Re: [PATCH] builddeb: introduce variables for control-file customization

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]

On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:
> The debian packages coming out of "make *deb-pkg" lack some critical
> information in the control-files e.g. the "Depends:" field. If one
> tries to install a fresh system with such a "linux-image" debootstrap or
> multistrap might try to install the kernel before its deps and the
> package hooks will fail.

I assume you're talking about those hook scripts being run while the
packages they belong to are only unpacked?  I hadn't thought about this
issue, but it seems to me that those hook scripts generally ought to be
fixed to handle this case properly.  Most of the packages installing
hook scripts for kernel packages are not going to be dependencies of
linux-image packages, so it will never be safe for them to assume their
package has been fully installed.

> Different debian-based distros use different values for the missing
> fields. And the values differ between distro versions as well. So
> hardcoding of e.g. "Depends" is not possible.

The dependencies also depend on the kernel configuration.  (And a
custom kernel built with 'make deb-pkg' often won't have any
dependencies outside of essential packages.)

> This patch introduces an option variable for every debian package built
> by builddeb. That allows advanced users to pass additional arguments to
> "dpkg-gencontrol" e.g. to set "Depends". All the new variables are
> optional.

This customisation mechanism seems too powerful to be maintainable. 
There is a high risk that it would conflict with later improvements to
builddeb, either resulting in regressions or blocking those
improvements from being made.

> for example:
> make \
> 	KDEB_OPTS_IMAGE=\
> "-DDepends='initramfs-tools | linux-initramfs-tool, kmod, linux-base'" \
[...]

The maintainer scripts generated by builddeb currently don't run depmod
or any of the script in linux-base.  So this seems like a bad example. 
However, the dependency on initramfs-tools is an important one that
can't simply be inferred from the kernel configuration.

So I would support adding a means to append to the Depends field
specifically.  Appending to the Breaks field may also be useful, as new
kernel versions may break specific utilities or user-space drivers.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Fri, 1 Dec 2017 16:51:12 +0000
schrieb Ben Hutchings <ben@decadent.org.uk>:

> On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:
> > The debian packages coming out of "make *deb-pkg" lack some critical
> > information in the control-files e.g. the "Depends:" field. If one
> > tries to install a fresh system with such a "linux-image"
> > debootstrap or multistrap might try to install the kernel before
> > its deps and the package hooks will fail.  
> 
> I assume you're talking about those hook scripts being run while the
> packages they belong to are only unpacked?  I hadn't thought about
> this issue, but it seems to me that those hook scripts generally
> ought to be fixed to handle this case properly.  Most of the packages
> installing hook scripts for kernel packages are not going to be
> dependencies of linux-image packages, so it will never be safe for
> them to assume their package has been fully installed.

Yes these hook scripts fail when installing the kernel on another
system. Indeed we seem to have a case where packages installed on the
build-machine cause install-time deps for the package.
In my case the build-machine is pretty minimal but i still want some of
that i.e. initramfs.

> > Different debian-based distros use different values for the missing
> > fields. And the values differ between distro versions as well. So
> > hardcoding of e.g. "Depends" is not possible.  
> 
> The dependencies also depend on the kernel configuration.  (And a
> custom kernel built with 'make deb-pkg' often won't have any
> dependencies outside of essential packages.)

In fact it does not have any at the moment, there is no essential. Or
maybe that is hidden in debian-magic.

> > This patch introduces an option variable for every debian package
> > built by builddeb. That allows advanced users to pass additional
> > arguments to "dpkg-gencontrol" e.g. to set "Depends". All the new
> > variables are optional.  
> 
> This customisation mechanism seems too powerful to be maintainable. 
> There is a high risk that it would conflict with later improvements to
> builddeb, either resulting in regressions or blocking those
> improvements from being made.

Fair enough. But there needs to be a way to specifiy at least some
deps, inheriting them from the build-host would be wrong. I really just
care about deps but thought this powerful tool would be a good idea in
case anyone cares about suggest and recommend etc..

> > for example:
> > make \
> > 	KDEB_OPTS_IMAGE=\
> > "-DDepends='initramfs-tools | linux-initramfs-tool, kmod,
> > linux-base'" \  
> [...]
> 
> The maintainer scripts generated by builddeb currently don't run
> depmod or any of the script in linux-base.  So this seems like a bad
> example. However, the dependency on initramfs-tools is an important
> one that can't simply be inferred from the kernel configuration.

Adding a depmod hook would probably be another patch. Let us keep that
in mind.

> So I would support adding a means to append to the Depends field
> specifically.  Appending to the Breaks field may also be useful, as
> new kernel versions may break specific utilities or user-space
> drivers.

Ok, in that case i will come up with another patch introducing
KDEB_IMAGE_DEPENDS KDEB_HEADERS_DEPENDS etc. and maybe _BREAKS as well.

Those would be appended when the control-files are generated. i.e.

cat EOF...
Depends: foo bar $KDEB_IMAGE_DEPENDS
EOF

Henning
 
> Ben.
> 

Re: [PATCH] builddeb: introduce variables for control-file customization

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

On Fri, 2017-12-01 at 19:34 +0100, Henning Schild wrote:
> Am Fri, 1 Dec 2017 16:51:12 +0000
> schrieb Ben Hutchings <ben@decadent.org.uk>:
> 
> > On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:
> > > The debian packages coming out of "make *deb-pkg" lack some critical
> > > information in the control-files e.g. the "Depends:" field. If one
> > > tries to install a fresh system with such a "linux-image"
> > > debootstrap or multistrap might try to install the kernel before
> > > its deps and the package hooks will fail.  
> > 
> > I assume you're talking about those hook scripts being run while the
> > packages they belong to are only unpacked?  I hadn't thought about
> > this issue, but it seems to me that those hook scripts generally
> > ought to be fixed to handle this case properly.  Most of the packages
> > installing hook scripts for kernel packages are not going to be
> > dependencies of linux-image packages, so it will never be safe for
> > them to assume their package has been fully installed.
> 
> Yes these hook scripts fail when installing the kernel on another
> system. Indeed we seem to have a case where packages installed on the
> build-machine cause install-time deps for the package.

Can you give an example?  I don't see how that would happen.

> In my case the build-machine is pretty minimal but i still want some of
> that i.e. initramfs.
> 
> > > Different debian-based distros use different values for the missing
> > > fields. And the values differ between distro versions as well. So
> > > hardcoding of e.g. "Depends" is not possible.  
> > 
> > The dependencies also depend on the kernel configuration.  (And a
> > custom kernel built with 'make deb-pkg' often won't have any
> > dependencies outside of essential packages.)
> 
> In fact it does not have any at the moment, there is no essential. Or
> maybe that is hidden in debian-magic.
[...]

Essential packages are always installed, which means there is no need
to declare a dependency on them (in fact it is discouraged):
https://www.debian.org/doc/debian-policy/#dependencies

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] builddeb: introduce variables for control-file customization

[Henning Schild]

Am Fri, 1 Dec 2017 18:47:38 +0000
schrieb Ben Hutchings <ben@decadent.org.uk>:

> On Fri, 2017-12-01 at 19:34 +0100, Henning Schild wrote:
> > Am Fri, 1 Dec 2017 16:51:12 +0000
> > schrieb Ben Hutchings <ben@decadent.org.uk>:
> >   
> > > On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:  
> > > > The debian packages coming out of "make *deb-pkg" lack some
> > > > critical information in the control-files e.g. the "Depends:"
> > > > field. If one tries to install a fresh system with such a
> > > > "linux-image" debootstrap or multistrap might try to install
> > > > the kernel before its deps and the package hooks will fail.    
> > > 
> > > I assume you're talking about those hook scripts being run while
> > > the packages they belong to are only unpacked?  I hadn't thought
> > > about this issue, but it seems to me that those hook scripts
> > > generally ought to be fixed to handle this case properly.  Most
> > > of the packages installing hook scripts for kernel packages are
> > > not going to be dependencies of linux-image packages, so it will
> > > never be safe for them to assume their package has been fully
> > > installed.  
> > 
> > Yes these hook scripts fail when installing the kernel on another
> > system. Indeed we seem to have a case where packages installed on
> > the build-machine cause install-time deps for the package.  
> 
> Can you give an example?  I don't see how that would happen.

Scripts in /etc/kernel/ will end up as hooks for the kernel-package, if
you do not set KDEB_HOOKDIR. Looking at an example system that pulls in
things like "pm-utils, grub-pc .. initramfs". With this mechanism any
package placing a hook in /etc/kernel can influence the deps. I guess
in practice that is prevented with policies on what these scripts are
allowed to do.

> > In my case the build-machine is pretty minimal but i still want
> > some of that i.e. initramfs.
> >   
> > > > Different debian-based distros use different values for the
> > > > missing fields. And the values differ between distro versions
> > > > as well. So hardcoding of e.g. "Depends" is not possible.    
> > > 
> > > The dependencies also depend on the kernel configuration.  (And a
> > > custom kernel built with 'make deb-pkg' often won't have any
> > > dependencies outside of essential packages.)  
> > 
> > In fact it does not have any at the moment, there is no essential.
> > Or maybe that is hidden in debian-magic.  
> [...]
> 
> Essential packages are always installed, which means there is no need
> to declare a dependency on them (in fact it is discouraged):
> https://www.debian.org/doc/debian-policy/#dependencies

Ok, i will need to double-check how multistrap deals with those.

Henning

> Ben.
> 

Re: [PATCH] builddeb: introduce variables for control-file customization

[Riku Voipio]

On 4 December 2017 at 11:01, Henning Schild <henning.schild@siemens.com> wrote:
> Am Fri, 1 Dec 2017 18:47:38 +0000
> schrieb Ben Hutchings <ben@decadent.org.uk>:
>
>> On Fri, 2017-12-01 at 19:34 +0100, Henning Schild wrote:
>> > Am Fri, 1 Dec 2017 16:51:12 +0000
>> > schrieb Ben Hutchings <ben@decadent.org.uk>:
>> >
>> > > On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:
>> > > > The debian packages coming out of "make *deb-pkg" lack some
>> > > > critical information in the control-files e.g. the "Depends:"
>> > > > field. If one tries to install a fresh system with such a
>> > > > "linux-image" debootstrap or multistrap might try to install
>> > > > the kernel before its deps and the package hooks will fail.

We don't usually install kernel during debootstrap.

>> > > I assume you're talking about those hook scripts being run while
>> > > the packages they belong to are only unpacked?  I hadn't thought
>> > > about this issue, but it seems to me that those hook scripts
>> > > generally ought to be fixed to handle this case properly.  Most
>> > > of the packages installing hook scripts for kernel packages are
>> > > not going to be dependencies of linux-image packages, so it will
>> > > never be safe for them to assume their package has been fully
>> > > installed.
>> >
>> > Yes these hook scripts fail when installing the kernel on another
>> > system. Indeed we seem to have a case where packages installed on
>> > the build-machine cause install-time deps for the package.
>>
>> Can you give an example?  I don't see how that would happen.
>
> Scripts in /etc/kernel/ will end up as hooks for the kernel-package, if
> you do not set KDEB_HOOKDIR. Looking at an example system that pulls in
> things like "pm-utils, grub-pc .. initramfs". With this mechanism any
> package placing a hook in /etc/kernel can influence the deps. I guess
> in practice that is prevented with policies on what these scripts are
> allowed to do.

This doesn't seem to be the case on my system. And from the bits that
handle debhookdir in scripts/package/builddeb, I don't see how this
is happening.

Re: [PATCH] builddeb: introduce variables for control-file customization

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Mon, 2017-12-04 at 10:01 +0100, Henning Schild wrote:
> Am Fri, 1 Dec 2017 18:47:38 +0000
> schrieb Ben Hutchings <ben@decadent.org.uk>:
> 
> > On Fri, 2017-12-01 at 19:34 +0100, Henning Schild wrote:
> > > Am Fri, 1 Dec 2017 16:51:12 +0000
> > > schrieb Ben Hutchings <ben@decadent.org.uk>:
> > >   
> > > > On Fri, 2017-12-01 at 15:56 +0000, Henning Schild wrote:  
> > > > > The debian packages coming out of "make *deb-pkg" lack some
> > > > > critical information in the control-files e.g. the "Depends:"
> > > > > field. If one tries to install a fresh system with such a
> > > > > "linux-image" debootstrap or multistrap might try to install
> > > > > the kernel before its deps and the package hooks will fail.    
> > > > 
> > > > I assume you're talking about those hook scripts being run while
> > > > the packages they belong to are only unpacked?  I hadn't thought
> > > > about this issue, but it seems to me that those hook scripts
> > > > generally ought to be fixed to handle this case properly.  Most
> > > > of the packages installing hook scripts for kernel packages are
> > > > not going to be dependencies of linux-image packages, so it will
> > > > never be safe for them to assume their package has been fully
> > > > installed.  
> > > 
> > > Yes these hook scripts fail when installing the kernel on another
> > > system. Indeed we seem to have a case where packages installed on
> > > the build-machine cause install-time deps for the package.  
> > 
> > Can you give an example?  I don't see how that would happen.
> 
> Scripts in /etc/kernel/ will end up as hooks for the kernel-package, if
> you do not set KDEB_HOOKDIR. Looking at an example system that pulls in
> things like "pm-utils, grub-pc .. initramfs". With this mechanism any
> package placing a hook in /etc/kernel can influence the deps.
[...]

That is not a dependency.  That is an extension mechanism.

Ben.

-- 
Ben Hutchings
Lowery's Law:
        If it jams, force it. If it breaks, it needed replacing anyway.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v2] scripts: builddeb: allow customization of "Depends:" fields

[Henning Schild]

The debian packages coming out of "make *deb-pkg" lack the "Depends:"
field. If one tries to install a fresh system with such a "linux-image"
debootstrap or multistrap might try to install the kernel before its
deps and the package hooks will fail.

Different debian-based distros use different values for the missing
fields. And the values differ between distro versions as well. So
hardcoding is not possible.

This patch introduces an option variable for every debian package built
by builddeb. That allows advanced users to specify additional
dependencies for all packages. All the new variables are optional.

Signed-off-by: Henning Schild <henning.schild@siemens.com>
---
 scripts/package/builddeb | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index b4f0f2b3f8d2..079bd4c4aea9 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -288,6 +288,7 @@ if [ "$ARCH" = "um" ]; then
 
 Package: $packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE
 Description: User Mode Linux kernel, version $version
  User-mode Linux is a port of the Linux kernel to its own system call
  interface.  It provides a kind of virtual machine, which runs Linux
@@ -304,6 +305,7 @@ else
 
 Package: $packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE
 Description: Linux kernel, version $version
  This package contains the Linux kernel, modules and corresponding other
  files, version: $version.
@@ -335,6 +337,7 @@ cat <<EOF >> debian/control
 
 Package: $kernel_headers_packagename
 Architecture: any
+Depends: $KDEB_DEP_IMAGE_HEADERS
 Description: Linux kernel headers for $KERNELRELEASE on \${kernel:debarch}
  This package provides kernel header files for $KERNELRELEASE on \${kernel:debarch}
  .
@@ -347,6 +350,7 @@ Package: $libc_headers_packagename
 Section: devel
 Provides: linux-kernel-headers
 Architecture: any
+Depends: $KDEB_DEP_LIBC_HEADERS
 Description: Linux support headers for userspace development
  This package provides userspaces headers from the Linux kernel.  These headers
  are used by the installed headers for GNU glibc and other system libraries.
@@ -375,6 +379,7 @@ if [ -n "$BUILD_DEBUG" ] ; then
 
 Package: $dbg_packagename
 Section: debug
+Depends: $KDEB_DEP_IMAGE_DBG
 Architecture: any
 Description: Linux kernel debugging symbols for $version
  This package will come in handy if you need to debug the kernel. It provides
-- 
2.13.6

Re: [PATCH v2] scripts: builddeb: allow customization of "Depends:" fields

[Henning Schild]

Hi,

this is a simpler version that allows just the customization of
"Depends:", as requested by Ben.

It addresses the security issues Jim mentioned by not using eval
anymore.

Henning

Am Mon, 4 Dec 2017 17:48:08 +0100
schrieb Henning Schild <henning.schild@siemens.com>:

> The debian packages coming out of "make *deb-pkg" lack the "Depends:"
> field. If one tries to install a fresh system with such a
> "linux-image" debootstrap or multistrap might try to install the
> kernel before its deps and the package hooks will fail.
> 
> Different debian-based distros use different values for the missing
> fields. And the values differ between distro versions as well. So
> hardcoding is not possible.
> 
> This patch introduces an option variable for every debian package
> built by builddeb. That allows advanced users to specify additional
> dependencies for all packages. All the new variables are optional.
> 
> Signed-off-by: Henning Schild <henning.schild@siemens.com>
> ---
>  scripts/package/builddeb | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index b4f0f2b3f8d2..079bd4c4aea9 100755
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -288,6 +288,7 @@ if [ "$ARCH" = "um" ]; then
>  
>  Package: $packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE
>  Description: User Mode Linux kernel, version $version
>   User-mode Linux is a port of the Linux kernel to its own system call
>   interface.  It provides a kind of virtual machine, which runs Linux
> @@ -304,6 +305,7 @@ else
>  
>  Package: $packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE
>  Description: Linux kernel, version $version
>   This package contains the Linux kernel, modules and corresponding
> other files, version: $version.
> @@ -335,6 +337,7 @@ cat <<EOF >> debian/control
>  
>  Package: $kernel_headers_packagename
>  Architecture: any
> +Depends: $KDEB_DEP_IMAGE_HEADERS
>  Description: Linux kernel headers for $KERNELRELEASE on
> \${kernel:debarch} This package provides kernel header files for
> $KERNELRELEASE on \${kernel:debarch} .
> @@ -347,6 +350,7 @@ Package: $libc_headers_packagename
>  Section: devel
>  Provides: linux-kernel-headers
>  Architecture: any
> +Depends: $KDEB_DEP_LIBC_HEADERS
>  Description: Linux support headers for userspace development
>   This package provides userspaces headers from the Linux kernel.
> These headers are used by the installed headers for GNU glibc and
> other system libraries. @@ -375,6 +379,7 @@ if [ -n "$BUILD_DEBUG"
> ] ; then 
>  Package: $dbg_packagename
>  Section: debug
> +Depends: $KDEB_DEP_IMAGE_DBG
>  Architecture: any
>  Description: Linux kernel debugging symbols for $version
>   This package will come in handy if you need to debug the kernel. It
> provides