Received-SPF: pass (google.com: domain of linux-kernel+bounces-3824-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <CAK7LNAT3N82cJD3GsF+yUBEfPNOBkhzYPk37q3k0HdU7ukz9vQ@mail.gmail.com>
 <baa3224bece94220dfe7173432143a91f7612c09.1701892062.git.msuchanek@suse.de>
 <CAK7LNARdnt0QXn6TRbuS_wzzMVXTY6NrCnu9WOM6PFztnyRmuQ@mail.gmail.com>
 <20231210210859.GN9696@kitsune.suse.cz> <CAK7LNAQo1p3dmdoqQRM_JxBp78Rxj5YpVqXGzMr5Xs9K-V3BiA@mail.gmail.com>
 <20231212131219.GQ9696@kitsune.suse.cz>
In-Reply-To: <20231212131219.GQ9696@kitsune.suse.cz>
From: Masahiro Yamada <masahiroy@kernel.org>
Date: Mon, 18 Dec 2023 23:16:48 +0900
Message-ID: <CAK7LNASb4Gt-pQncBv3KLG=P1UtehgHNCgY8XeaQ_vfdUuSQRg@mail.gmail.com>
Subject: Re: [PATCH v6 2/2] kbuild: rpm-pkg: Fix build with non-default MODLIB
To: =?UTF-8?Q?Michal_Such=C3=A1nek?= <msuchanek@suse.de>
Cc: linux-modules@vger.kernel.org, Takashi Iwai <tiwai@suse.com>, 
	Lucas De Marchi <lucas.de.marchi@gmail.com>, =?UTF-8?Q?Michal_Koutn=C3=BD?= <mkoutny@suse.com>, 
	Jiri Slaby <jslaby@suse.com>, Jan Engelhardt <jengelh@inai.de>, Nathan Chancellor <nathan@kernel.org>, 
	Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, 
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 12, 2023 at 10:12=E2=80=AFPM Michal Such=C3=A1nek <msuchanek@su=
se.de> wrote:
>
> On Mon, Dec 11, 2023 at 01:33:23PM +0900, Masahiro Yamada wrote:
> > On Mon, Dec 11, 2023 at 6:09=E2=80=AFAM Michal Such=C3=A1nek <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=E2=80=AFAM Michal Suchanek <msuchanek@s=
use.de> wrote:
> > > > >
> > > > > The default MODLIB value is composed of three variables
> > > > >
> > > > > MODLIB =3D $(INSTALL_MOD_PATH)$(KERNEL_MODULE_DIRECTORY)/$(KERNEL=
RELEASE)
> > > > >
> > > > > However, the kernel.spec hadcodes the default value of
> > > > > $(KERNEL_MODULE_DIRECTORY), and changed value is not reflected wh=
en
> > > > > 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 decisio=
n.
> >
> > '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 ?=3D 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


--=20
Best Regards
Masahiro Yamada