Re: [PATCH 1/2] package: add tar development package for 3rd party modules

From: Randy Dunlap
Date: Fri Oct 21 2022 - 18:28:57 EST




On 10/21/22 14:48, Federico Vaga wrote:
> On Fri, Oct 21, 2022 at 01:11:18PM -0700, Randy Dunlap wrote:
>> Hi--
>>
>> On 10/21/22 03:14, Federico Vaga wrote:
>>> Most, if not all, Linux distributions provides a Linux development
>>> package which purpose is to support the building of out-of-tree modules
>>> without providing the entire source tree.
>>>
>>> What ends up in this development directory is a mixture of source
>>> files (mainly headers) and generated ones (headers, and tools produced
>>> by `make modules_prepare`).
>>>
>>> This patch is an attempt to generate a tarball archive containing all
>>> required files to build external modules. It could be than reused by
>>> packagers.
>>>
>>> Signed-off-by: Federico Vaga <federico.vaga@xxxxxxx>
>>> ---
>>>  Makefile                       |   2 +-
>>>  scripts/Makefile.package       |  13 +++
>>>  scripts/package/buildtar-devel | 207 +++++++++++++++++++++++++++++++++
>>>  3 files changed, 221 insertions(+), 1 deletion(-)
>>>  create mode 100644 scripts/package/buildtar-devel
>>
>> Is there a patch 2/2?  I don't see it anywhere.
>
> My mistake.
>
> Yes there is a second one but I did not want to send it becuase it is about
> generalizing buildtar to build 3 type of tarballs: the linux binaries to be
> placed in /boot, the header files for user-space, and the development headers
> and tools for out-of-tree modules (this patch).

Ah, I was wondering why this change was included:

diff --git a/Makefile b/Makefile
index cfbe6a7de640..36a58394ce16 100644
--- a/Makefile
+++ b/Makefile
@@ -1578,7 +1578,7 @@ CLEAN_FILES += include/ksym vmlinux.symvers modules-only.symvers \
# Directories & files removed with 'make mrproper'
MRPROPER_FILES += include/config include/generated \
arch/$(SRCARCH)/include/generated .objdiff \
- debian snap tar-install \
+ debian snap tar-install* \
.config .config.old .version \
Module.symvers \
certs/signing_key.pem \

so I think that you just explained it.

> The second one makes sense, only if this one makes sense. That's why I wrote few
> lines in the RFC cover letter. I should have used the format-patch option to not
> enumerate patches :)
>
>> thanks.
>> -- 
>> ~Randy
>

--
~Randy