Re: [PATCH v6 2/2] kbuild: rpm-pkg: Fix build with non-default MODLIB

[Masahiro Yamada <masahiroy@kernel.org>]

On Tue, Dec 12, 2023 at 10:12 PM Michal Suchánek <msuchanek@suse.de> wrote:
>
> On Mon, Dec 11, 2023 at 01:33:23PM +0900, Masahiro Yamada wrote:
> > On Mon, Dec 11, 2023 at 6:09 AM Michal Suchánek <msuchanek@suse.de> wrote:
> > >
> > > On Mon, Dec 11, 2023 at 03:44:35AM +0900, Masahiro Yamada wrote:
> > > > On Thu, Dec 7, 2023 at 4:48 AM Michal Suchanek <msuchanek@suse.de> wrote:
> > > > >
> > > > > The default MODLIB value is composed of three variables
> > > > >
> > > > > MODLIB = $(INSTALL_MOD_PATH)$(KERNEL_MODULE_DIRECTORY)/$(KERNELRELEASE)
> > > > >
> > > > > However, the kernel.spec hadcodes the default value of
> > > > > $(KERNEL_MODULE_DIRECTORY), and changed value is not reflected when
> > > > > building the package.
> > > > >
> > > > > Pass KERNEL_MODULE_DIRECTORY to kernel.spec to fix this problem.
> > > > >
> > > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > > > > ---
> > > > > Build on top of the previous patch adding KERNEL_MODULE_DIRECTORY
> > > >
> > > >
> > > > The SRPM package created by 'make srcrpm-pkg' may not work
> > > > if rpmbuild is executed in a different machine.
> > >
> > > That's why there is an option to override KERNEL_MODULE_DIRECTORY?
> >
> >
> > Yes.
> > But, as I pointed out in 1/2, depmod must follow the packager's decision.
> >
> > 'make srcrpm-pkg' creates a SRPM on machine A.
> > 'rpmbuild' builds it into binary RPMs on machine B.
> >
> > If A and B disagree about kmod.pc, depmod will fail
> > because there is no code to force the decision made
> > on machine A.
>
> There is. It's the ?= in the top Makefile.


Nope.


Only Kbuild follows the specified KERNEL_MODULE_DIRECTORY.


depmod still uses the MODULE_DRECTORY determined
when it was compiled.


>
> Currently the test that determines the module directory uses make logic
> so it's not possible to pass on the shell magic before executing it so
> it could be executed inside the rpm spec file as well.
>
> OUtsourcing it into an external script would mean that the sources need
> to be unpacked before the script can be executed. That would require
> using dynamically generated file list in the spec file because the
> module location would not be known at spec parse time. Possible but
> convoluted.


I do not require that.


This is simple; builders must follow the packager's decision.

To make it work, depmod must follow MODULE_DIRECTORY
given from an external environment.





> In the end I do not think this is a problem that needs solving. Most
> distributions that build kernel packages would use their own packaging
> files, not rpm-pkg. That limits rpm-pkg to ad-hoc use when people want
> to build one-off test kernel. It's reasonable to do on the same
> distribution as the target system. The option to do so on a distribution
> with different module directory is available if somebody really needs
> that.
>
> Thanks
>
> Michal



-- 
Best Regards
Masahiro Yamada