From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FFB6C4167B for ; Tue, 12 Dec 2023 13:12:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235212AbjLLNMS (ORCPT ); Tue, 12 Dec 2023 08:12:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232611AbjLLNMQ (ORCPT ); Tue, 12 Dec 2023 08:12:16 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E70CAA8; Tue, 12 Dec 2023 05:12:22 -0800 (PST) Received: from kitsune.suse.cz (unknown [10.100.12.127]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 038511FB45; Tue, 12 Dec 2023 13:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1702386741; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SFfoLmv98r2NNTJcot2GCx6avTvSu3XvUhkt/4Goo/o=; b=DZsd9SgxbHOr1kIQj4Ysq6IB0aUH8X96Xfv1/ho8Wr+UnS6JOqii7w0F3dm+mDIMjXT/p9 KFJ1J7P2MA7sKJavr30t4BgPwEed2Ek2r7fT1BY1F1ICRgElTXuV8S6jq+2CzouepLNcN3 rnk7h4comPmc5bF3t4gOSjqFXyaKRLU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1702386741; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SFfoLmv98r2NNTJcot2GCx6avTvSu3XvUhkt/4Goo/o=; b=qB5n7u3qQTlJlDN47X6cQuY0HjP+xNgyuo0UO9evecfzd9gPHG2GQxNQtuqonQU1pRsojD /Ljg6MmkXMRTfsCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1702386741; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SFfoLmv98r2NNTJcot2GCx6avTvSu3XvUhkt/4Goo/o=; b=DZsd9SgxbHOr1kIQj4Ysq6IB0aUH8X96Xfv1/ho8Wr+UnS6JOqii7w0F3dm+mDIMjXT/p9 KFJ1J7P2MA7sKJavr30t4BgPwEed2Ek2r7fT1BY1F1ICRgElTXuV8S6jq+2CzouepLNcN3 rnk7h4comPmc5bF3t4gOSjqFXyaKRLU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1702386741; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SFfoLmv98r2NNTJcot2GCx6avTvSu3XvUhkt/4Goo/o=; b=qB5n7u3qQTlJlDN47X6cQuY0HjP+xNgyuo0UO9evecfzd9gPHG2GQxNQtuqonQU1pRsojD /Ljg6MmkXMRTfsCA== Date: Tue, 12 Dec 2023 14:12:19 +0100 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: Masahiro Yamada Cc: linux-modules@vger.kernel.org, Takashi Iwai , Lucas De Marchi , Michal =?iso-8859-1?Q?Koutn=FD?= , Jiri Slaby , Jan Engelhardt , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 2/2] kbuild: rpm-pkg: Fix build with non-default MODLIB Message-ID: <20231212131219.GQ9696@kitsune.suse.cz> References: <20231210210859.GN9696@kitsune.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: smtp-out2.suse.de; none X-Spamd-Result: default: False [-2.80 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-0.996]; RCPT_COUNT_TWELVE(0.00)[12]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_CC(0.00)[vger.kernel.org,suse.com,gmail.com,inai.de,kernel.org,google.com,fjasle.eu]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[] Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 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 > > > > --- > > > > 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. 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. 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