Re: [OE-core] [PATCH] kernel.bbclass: install .config to deploy dir

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Wed, Feb 07, 2024 at 02:14:33PM +0100, Matthias Schiffer wrote:
> On Wed, 2024-02-07 at 12:42 +0000, Bruce Ashfield wrote:
> > On Wed, Feb 7, 2024 at 5:26 AM Matthias Schiffer
> > <matthias.schiffer@ew.tq-group.com> wrote:
> > > 
> > > Deploy the kernel configuration with the built images, so it is easy to
> > > check its contents, or rebuild the same configuration outside of the
> > > Yocto build system.
> > > 
> > 
> > I'm not convinced we need yet more clutter in the deploy directory, but
> > at a minimum, this patch also needs an update to the documentation
> > (apologies if I missed it on the docs list).
> 
> Sorry about the missing docs, I'll provide a patch for that as well.
> 
> > 
> > One could argue that the config could be pulled out of the other
> > packages and artifacts, and that it wouldn't be recommended to
> > use that config for rebuilding outside of yocto, as we aren't providing
> > the matching sources in the deploy directory.
> 
> There are at least some cases where the config can't be pulled out of anything else - without
> CONFIG_IKCONFIG, the config is not embedded in the built kernel images. In constrained environments,
> it may be desirable to disable such options to reduce the kernel size.
> 
> As a data point from other distros, Debian/Ubuntu disable CONFIG_IKCONFIG and instead provide the
> config next to the kernel images in /boot.

Check the kernel-dev package. The config is there.

> > 
> > I would also be nice in the commit log to indicate how cleanup of the
> > deploydir has been tested to show that we won't end up with config*
> > files and links in the directory after their associated images have been
> > removed. (I haven't looked at the deploy classes in quite some time,
> > so I'm unsure if anything in particular needs to be done).
> 
> My understanding is that unclean deploy dir issues are pretty much a thing of the past, as
> deploy.bbclass sets `do_deploy[cleandirs] = "${DEPLOYDIR}"` (so do_deploy always starts with
> a pristine destination directory), and the sstate tracking takes care of the rest. 

I agree that deploy directories have way too many things already. And recipes often get it wrong trying
to pass files through it from providers to users without setting task dependendencies and sstate caching
correctly.

Cheers,

-Mikko