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

From: Riku Voipio
Date: Mon Dec 04 2017 - 08:15:34 EST


On 4 December 2017 at 11:01, Henning Schild <henning.schild@xxxxxxxxxxx> wrote:
> Am Fri, 1 Dec 2017 18:47:38 +0000
> schrieb Ben Hutchings <ben@xxxxxxxxxxxxxxx>:
>
>> 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@xxxxxxxxxxxxxxx>:
>> >
>> > > 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.