Upstream Linux 6.11 Makes It Easy To Build A Pacman Kernel Package For Arch Linux

[phoronix]

Phoronix: Upstream Linux 6.11 Makes It Easy To Build A Pacman Kernel Package For Arch Linux

The upstream Linux 6.11 kernel is making it easier to build a Pacman package of the kernel for use on Arch Linux and other Arch derived distributions relying on Pacman...

https://www.phoronix.com/news/Linux-6.11-Pacman-Arch-Linux

[timofonic]

Best useful Linux kernel feature in years.

Add aggressive best hardware mainline hardware driver suppoort of smartphone, ARM, MIPS, RISC-V, PPC and POWER... and I'll only buy that Linux friendly hardware.

[luno]

this is nice, every distro should make custom kernel build easier with docs, debugging linux kernel from vscode is so smooth nowdays

[Sethox]

I am all for such a feature such as this. But it seems weird to me to be upstreamed in the kernel. So well written code for APT/DNF and other package managers (of same caliber as this merge) can also be submitted then?

I obviously don't know the backstory/history to this inclusion..

[rhysperry111]

Interesting - what's the use-case here if it's already extremely easy to work with Arch's upstream PKGBUILD pointed to a custom source?

[ptr1337]

Interesting - what's the use-case here if it's already extremely easy to work with Arch's PKGBUILD pointed to a custom source?

Its thought to build directly from the development/kernel tree and then package it. Also, it does not strip debug stuff out, like archlinux currently does as default.

[barti_ddu]

I am all for such a feature such as this. But it seems weird to me to be upstreamed in the kernel. So well written code for APT/DNF and other package managers (of same caliber as this merge) can also be submitted then?

I obviously don't know the backstory/history to this inclusion..

It is already there (e.g. bindeb-pkg target for building debian package).

[ayumu]

Better uninstall handling... it would be nice if this meant uninstall of kernel modules for the running kernel was delayed until it is no longer running.

[rene]

waste of code and time. Distro specific fluff should not be upstream. Imagine if all the 2047 Linux distribution add all their crap to the Linux kernel and each other package.

[ayumu]

waste of code and time. Distro specific fluff should not be upstream. Imagine if all the 2047 Linux distribution add all their crap to the Linux kernel and each other package.

Of these 2047, how many are not derivatives of e.g. Fedora/Debian/Ubuntu? And how many have a significant body of users?

Arch is not negligible.

If we are to talk waste of time, then we should select a microkernel multiserver system and focus on propelling it forward, rather than doing anything with Linux.