Date: Fri, 1 Dec 2017 19:34:33 +0100
From: Henning Schild <henning.schild@siemens.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: <linux-kernel@vger.kernel.org>,
        Ben Hutchings <ben.hutchings@codethink.co.uk>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Michal Marek <michal.lkml@markovi.net>, <linux-kbuild@vger.kernel.org>,
        Konrad Schwarz <konrad.schwarz@siemens.com>
Subject: Re: [PATCH] builddeb: introduce variables for control-file
 customization
Message-ID: <20171201193433.68b25efe@md1em3qc>
In-Reply-To: <1512147072.2785.20.camel@decadent.org.uk>
References: <20171127161345.17880-1-henning.schild@siemens.com>
        <1512147072.2785.20.camel@decadent.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3444
Lines: 83

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