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. > > 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
