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

[Ben Hutchings]

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: signature.asc
Description: This is a digitally signed message part