not renaming the package and modifying pkgrel can indeed lead me to confusion, but it's just personal compilation. ok : good practices you encourage ;-) version 6.1.20 has just been downloaded and will be soon in place but my question remains : how to target 6.1.15 when evolving under 6.x.y (or 6.1.z) ? virtual machine (this is what I use to get around the problem but it seems pretty heavy) ? "cross" compilation ? make parameters ? environment variables ? thank you for these precisions which unfortunately do not enlighten me much :-( regards, lacsaP. Le lun. 20 mars 2023 à 11:02, Genes Lists a écrit :

On 3/20/23 05:27, lacsaP Patatetom wrote:

...

hi,

- When you change the source you must also bump pkgrel as the package is now different.

- If you want to build your own version of an Arch package, you should not use same package name as the official Arch package - this will only lead to bad things. Change the package name to something else.

- current kernel LTS is 6.1.20 so probably you should throw away 6.1.15 and use that anyway.

best,

gene

On Mon, 20 Mar 2023 at 11:00, Genes Lists wrote:

On 3/20/23 06:44, lacsaP Patatetom wrote:

Please don't top post on mailing lists.

Honestly, my best advice to you is stop trying to build kernels.

Hmm the saying to give a person a fish feeds them for a day, teach them how to fish and you feed them for their lifetime comes to mind. Just saying "stop doing" what they want to be doing is in bad taste in my opinion.

Hi, I'm not sure if I understand what the OP tries to achieve. I install "linux" and "linux-rt-lts" from repositories, but build "linux-rt" myself. To keep different versions of "linux-rt 4.19, I add an extension, "cornflower", "pussytoes" or "securityink". I misuse pkgrel to inform me if CONFIG_HZ is 1000 or 300. $ pacman -Q linux{,-rt{-lts,,-cornflower,-pussytoes,-securityink}}|awk '{print $1"\t"$2}' linux 6.2.7.arch1-1 linux-rt-lts 5.15.96.61.realtime1-1 linux-rt 1:4.19.277_rt122-0.1000 linux-rt-cornflower 1:4.19.271_rt120-0.300 linux-rt-pussytoes 1:4.19.269_rt119-0.300 linux-rt-securityink 1:4.19.265_rt117-0.300 IOW we can not install 2 different "linux", but we can install "linux-foo" and "Linux-bar", if we don't want to follow the approach of some other distros, that don't name the kernels "vmlinuz-linux", but "vmlinuz-4.5.6-7", so by this approach there is the need to edit the bootloader config or to change links each time a kernel gets updated. Regards, Ralf

if I understand correctly, I can install my package linux-lts-perso-6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?

The kernel headers are used to compile out-of-tree kernel modules for that kernel. You should always install kernel and its companion headers file. While there may be cases where the headers are not actually changed and it may work - good policy is always install both kernel and its companion headers package. If you don't compile out of tree kernel modules then you may not even need to install headers. Hope that is clear.

On Mon, 2023-03-20 at 07:42 -0400, Genes Lists wrote:

The kernel headers are used to compile out-of-tree kernel modules for that kernel. You should always install kernel and its companion headers file. While there may be cases where the headers are not actually changed and it may work - good policy is always install both kernel and its companion headers package. If you don't compile out of tree kernel modules then you may not even need to install headers.

I don't know if that's what the OP is asking for. There's no need to compile e.g. vim or bash against a new kernel version. But there is the need to compile e.g. virtualbox kernel modules against a new kernel version.

thank you for your feedback Ralf which is in line with Genes' explanations. the application that could fall into the mentioned category and that I am paying attention to is lvm, but previous tests show that this is not the case (the lvm2 package provided by ArchLinux behaves as expected with the recompiled modified kernel). regards, lacsaP. Le lun. 20 mars 2023 à 12:49, Ralf Mardorf a écrit :

On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote:

...

if I understand correctly, I can install my package linux-lts-perso- 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?

I still don't know if I understand you and https://www.google.com/search?q=translate doesn't help.

You can install

core/linux-lts 6.1.20-1 core/linux-lts-docs 6.1.20-1 core/linux-lts-headers 6.1.20-1

and also your

linux-lts-perso 6.1.15-2 linux-lts-perso-docs 6.1.15-2 linux-lts-perso-headers 6.1.15-2

neither the version, nor the pkgrel matter. You can run one or the other kernel and you can build modules for what ever kernel you like, see

https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modul... .

You (usually) can use a binary such as /usr/bin/vim with one or the other kernel, but you might need to build modules to use something like virtualbox.

In your case something like systemd or xorg is irrelevant, but something like this might depend closer on kernel versions, than vim does.

Regards, Ralf

hi everybody, if point #1 is now relatively clear to me (eg. out of tree kernel modules need to recompile, otherwise it should work with few exceptions), point #2 is still pending. so I rephrase my question hoping to find an answer ;-) my development workstation is running 6.1.20-1-lts and I made linux-lts-ro-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-ro-headers-6.1.15-1-x86_64.pkg.tar.zst packages on it : if now I want to compile on this development workstation applications to run on another workstation which is running 6.1.15-1-lts-ro, what should I do so that the compilation takes this specificity into account ? I saw that there was the gcc ‘--enable-kernel=version’ option : is it the solution ? if yes, how to introduce it during the traditional "./configure && make" ? regards, lacsaP. Le lun. 20 mars 2023 à 13:19, Jeronimo Garcia a écrit :

lvm is a good one , bpftrace and other tools that might rely on kernel hooks , or something specific module or statically compiled feature , but as Ralf said , the vast majority of user land applications can be used interchangeably with different kernels .

On Mon, 20 Mar 2023 at 11:59, lacsaP Patatetom wrote:

...

thank you for your feedback Ralf which is in line with Genes' explanations.

the application that could fall into the mentioned category and that I am paying attention to is lvm, but previous tests show that this is not the case (the lvm2 package provided by ArchLinux behaves as expected with the recompiled modified kernel).

regards, lacsaP.

Le lun. 20 mars 2023 à 12:49, Ralf Mardorf a écrit :

...

On Mon, 2023-03-20 at 12:27 +0100, lacsaP Patatetom wrote:

...

if I understand correctly, I can install my package linux-lts-perso- 6.1.15-2-x86_64.pkg.tar.zst, boot on it (eg. "my" kernel) and continue to use the binaries present on my system while they have not been compiled with its (new) headers and especially for the binaries that call the functions present in the blk-core.c file ?

I still don't know if I understand you and https://www.google.com/search?q=translate doesn't help.

You can install

core/linux-lts 6.1.20-1 core/linux-lts-docs 6.1.20-1 core/linux-lts-headers 6.1.20-1

and also your

linux-lts-perso 6.1.15-2 linux-lts-perso-docs 6.1.15-2 linux-lts-perso-headers 6.1.15-2

neither the version, nor the pkgrel matter. You can run one or the other kernel and you can build modules for what ever kernel you like, see

https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support#Rebuild_modul... .

You (usually) can use a binary such as /usr/bin/vim with one or the other kernel, but you might need to build modules to use something like virtualbox.

In your case something like systemd or xorg is irrelevant, but something like this might depend closer on kernel versions, than vim does.

Regards, Ralf

again thank you for explanations/clarifications. have a good day, regards, lacsaP. Le mar. 21 mars 2023 à 11:16, Genes Lists a écrit :

On 3/21/23 04:26, lacsaP Patatetom wrote:

...

hi everybody,

...

my development workstation is running 6.1.20-1-lts and I made linux-lts-ro-6.1.15-1-x86_64.pkg.tar.zst and linux-lts-ro-headers-6.1.15-1-x86_64.pkg.tar.zst packages on it : if now I want to compile on this development workstation applications to run on another workstation which is running 6.1.15-1-lts-ro, what should I do so that the compilation takes this specificity into account ?

Unless you are compiling kernel modules the answer is nothing. The kernel team takes great pains to ensure that user space will continue to work. Most of the kernel interface of the kernel with user space is mediated by libraries such as glibc.

You do need to be sure that your user-space environment is consistent between the compiling host and the application target. For example that the target machines run same version of glibc etc.

So short answer - if only difference between your compile machine and target application machine is kernel - there is nothing special you need to do.

Good luck.