Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2128292ybi; Thu, 4 Jul 2019 05:39:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqwu4yC0dYX2aL2STFBC+7LJgIvAaKHw0p8xiL8R7L8kMax5LhdEJkbpZT1ZuRFhYOGinJ+k X-Received: by 2002:a17:902:9a85:: with SMTP id w5mr47552176plp.221.1562243996131; Thu, 04 Jul 2019 05:39:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562243996; cv=none; d=google.com; s=arc-20160816; b=gP/jt4akHsrr2XE2genWlg2rErHfe1+3QOJRw8FxvbG58jD1qQULYGlNHtsILalahX 3TQ5UGbQcnu6+QKZp3ViY+PtJ4fLf9HRbaP8Iq46l8S4wujtQTQlmdwyNSvX8gE97UJs PMEJImHXmtj8n6URxkVLZS3pH0sV/XWxZZsXbrTKIL8R6DenEkc+x7wYSW556KAQB+fV H5NSsI25BGHV5QuDIsFDDclqEV6XO44heY3lUPu7pOU9KSSXi0OgViPivCKNkpIHefIN KD0mYUF5AexNsd2TcCca6NEQkObjVz+Jgio/J/JIQtxPXu3Buk6KsqoxUWyELV/ddVar PbMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=p3ZpbMQDELZw7zOUl2Oj+QszjVej6EZYQgyF5Z+Z6Ls=; b=XbZLhMsMXnRVbgoPg8/fA7NQJEeUsHZ+ky0rbaq3m9BSkr2ULhg6sirK7MJTfEdUAa LQIyIsKIge+hwLkN5ysfEJvF5/9i6uvHXgza/Yx3K61DxeDpypCiJlXRylODDViynVFG CbIGLw0MMhdQW5slrpwnjUtrnCRbqqcVWsZ9w0lhLI4jdagbVJ5l74PSmUct5ZGW2+K6 8MVSuom3c/LPxj9Wi6oIoJpr0zUDwwrcLT61KwMtrrv8dxoSoLvHwShDG0pASTU4T4cH 6w2oiMFVEgsZRkSvEQbRY4nSBW8hp3pxCbS7u9K9jbNfg/FPHOBmalntbJZA6ipeS0Uj MQGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y3si814873pge.429.2019.07.04.05.39.40; Thu, 04 Jul 2019 05:39:56 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727726AbfGDMjR (ORCPT + 99 others); Thu, 4 Jul 2019 08:39:17 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:48295 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727682AbfGDMjR (ORCPT ); Thu, 4 Jul 2019 08:39:17 -0400 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-02.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1hj116-0005xc-CT from Cedric_Hombourger@mentor.com ; Thu, 04 Jul 2019 05:39:12 -0700 Received: from [172.30.65.44] (137.202.0.90) by svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 4 Jul 2019 13:39:05 +0100 Subject: Re: [PATCH] builddeb: generate multi-arch friendly linux-libc-dev package To: Masahiro Yamada CC: , Michal Marek , Linux Kbuild mailing list , Linux Kernel Mailing List , Ben Hutchings , Riku Voipio References: <1560752096-1323-1-git-send-email-Cedric_Hombourger@mentor.com> From: Cedric Hombourger Message-ID: Date: Thu, 4 Jul 2019 14:39:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) To svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Yamada-san Thanks for your review of this patch. Answers below On 7/4/2019 2:43 AM, Masahiro Yamada wrote: > CCed a couple of people. > > On Mon, Jun 17, 2019 at 3:15 PM Cedric Hombourger > wrote: >> Debian-based distributions place libc header files in a machine >> specific directory (/usr/include/) instead of >> /usr/include/asm to support installation of the linux-libc-dev >> package from multiple architectures. Move headers installed by >> "make headers_install" accordingly. >> >> Signed-off-by: Cedric Hombourger >> Reviewed-by: Henning Schild >> --- >> scripts/package/builddeb | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/scripts/package/builddeb b/scripts/package/builddeb >> index b03dd56a4782..8f7afb3a84e9 100755 >> --- a/scripts/package/builddeb >> +++ b/scripts/package/builddeb >> @@ -132,6 +132,11 @@ fi >> if [ "$ARCH" != "um" ]; then >> $MAKE -f $srctree/Makefile headers_check >> $MAKE -f $srctree/Makefile headers_install INSTALL_HDR_PATH="$libc_headers_dir/usr" >> + # move asm headers to /usr/include//asm to match the structure >> + # used by Debian-based distros (to support multi-arch) >> + libc_mach=$($CC -dumpmachine) >> + mkdir $libc_headers_dir/usr/include/$libc_mach >> + mv $libc_headers_dir/usr/include/asm $libc_headers_dir/usr/include/$libc_mach/ >> fi >> >> # Install the maintainer scripts > > I am not sure but, > I just worried about the backward compatibility... this patch is actually addressing a compatibility problem with multi-arch capable distros (all the major Debian-based distros that I know of are) where the currently generated libc headers packages is placing arch specific headers where all arch compilers installed on the system would find them > Was this previously broken? yes (as noted above) but would only be seen on systems with multi-arch packages / development tools installed > I guess debian is using own control file > instead of the one in upstream kernel. > So, this is almost a matter for developers, I think. Correct. Debian and some others use their own. We (Mentor and Siemens) as well as other folks from the embedded community build embedded platforms using Debian as a base and recent kernels (so we can run Debian on e.g. recent Arm64 hardware designs). This is achieved by using Isar (https://github.com/ilbers/isar). The custom kernel recipe it provides uses builddeb since that feature is mainline. It also allows us to use custom kernels regardless of the Debian-based distro we use (Raspbian, Ubuntu, Debian, etc.) > How did debian-base distros managed this before, > and will this introduce no breakage? We would expect desktop distros to continue using their own debian/{control,rules} files but would recommend to have the .deb produce by the kernel be better aligned with Debian so we can swap their "old" kernels with recent LTS or recent HEAD kernels. Hope I was able to shed some light on our use-case / motivation. > Ben, > Could you comment on this? > >