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
Date: Fri, 1 Dec 2017 19:34:33 +0100 [thread overview]
Message-ID: <20171201193433.68b25efe@md1em3qc> (raw)
In-Reply-To: <1512147072.2785.20.camel@decadent.org.uk>
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.
>
next prev parent reply other threads:[~2017-12-01 18:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 16:13 [PATCH] builddeb: introduce variables for control-file customization Henning Schild
2017-11-27 23:57 ` Jim Davis
2017-11-28 8:41 ` Henning Schild
2017-12-01 16:51 ` Ben Hutchings
2017-12-01 18:34 ` Henning Schild [this message]
2017-12-01 18:47 ` Ben Hutchings
2017-12-04 9:01 ` Henning Schild
2017-12-04 13:15 ` Riku Voipio
2017-12-04 14:35 ` Ben Hutchings
2017-12-04 16:48 ` [PATCH v2] scripts: builddeb: allow customization of "Depends:" fields Henning Schild
2017-12-04 16:50 ` Henning Schild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171201193433.68b25efe@md1em3qc \
--to=henning.schild@siemens.com \
--cc=ben.hutchings@codethink.co.uk \
--cc=ben@decadent.org.uk \
--cc=konrad.schwarz@siemens.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).