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

[Alejandro Colomar]

Hi Aurelien,

On 7/25/22 19:39, Aurelien Jarno wrote:

On 2022-07-25 14:51, Alejandro Colomar wrote:

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?


I don't think so. You do not want to modify files provided by a package.


Yeah, maybe it's better that the packagers run that script at packaging 
time, instead of apt-get at install time.  But, the script would be a 
good thing, I think, independently of who runs it.



Cheers,

Alex


--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

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

[Aurelien Jarno]

On 2022-07-25 14:51, Alejandro Colomar wrote:
> 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).

In addition the goal is to switch to glibc 2.34 in the next weeks, not
that most problems related with the libpthread.so removal are
identified.

> 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?

I don't think so. You do not want to modify files provided by a package.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

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

[Florian Weimer]

* 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

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

[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?

Cheers,

Alex

--
Alejandro Colomar



OpenPGP_signature
Description: OpenPGP digital signature

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

[Florian Weimer]

* 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.

Thanks,
Florian