Bug#1015719: libc6-dev: Build glibc with latest packaged kernel version

[Florian Weimer <fweimer@redhat.com>]

* Alejandro Colomar:

> Hi Florian!
>
> On 7/25/22 12:38, Florian Weimer wrote:
>> * Alejandro Colomar via Libc-alpha:
>> 
>>> Is there an easy way to regenerate that header to get the tatest
>>> syscalls?  Maybe a command could be supplied so that users (or at
>>> least distributors) have it easy to regenerate them?  Maybe it already
>>> exists but it's not widely known?
>> I have recently backported the syscall-names.list updates to glibc
>> 2.34,
>> but not glibc 2.33.  It's a simple backport.
>> We could perhaps enhance the glibc build process that it uses the
>> union
>> of the known system call names and what's found in the kernel headers.
>
> I guess it's a simple backport, since it's just adding the macros (I
> guess 0 side effects).
>
> But maybe providing a script, e.g., update-libc-syscalls(1), that
> distributions and users can call when updating a kernel to immediately 
> backport syscalls to their system, would make it even simpler.
>
> E.g., when one runs `apt-get upgrade`, if the kernel is upgraded,
> update-libc-syscalls(1) would be called by apt-get as a post install 
> script, and libc macros would have the new syscall numbers provided by
> the new kernel.  No need to wait glibc programmers to provide the
> backport.
>
> Makes sense?

Sure, that's a possibility.  We don't do this in Fedora because RPM does
not have delayed script execution, so it's hard to make sure everything
is installed properly when the processing script runs.

Thanks,
Florian