On Thu, 16 Nov 2023 at 19:30, Bastian Blank <wa...@debian.org> wrote: > > Hi Dimitri > > On Thu, Nov 16, 2023 at 06:28:13PM +0000, Dimitri John Ledkov wrote: > > I have implemented example packaging of that as a standalone source package > > https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/ > > I actually just implemented something similar, but as part of the Debian > linux packaging. It looks a bit different, sure. >
Will check it out, thanks! And yes, indeed there are dozens of ways to implement this idea. > > Is this something that the debian kernel team could consider supporting / > > building as either standalone source package, or out of src:linux directly? > > My first thought was actually to make bootstrapping of new architectures > easier. > Indeed that too. But I was told "arm64" would the last one, and then "riscv64" is really the last one. Not sure if c-sky or riscv128 or arm64be will be next. > > The obvious things missing from the packaging is to create all the > > breaks/replaces/provides, and update cross-toolchain-base packages to > > match. Also probably using symlinks rather than hard links, with > > linux-libc-dev-cross likely depending on the native one. > > What do you want to do with linux-libc-dev-cross? /usr/$triplet is no > allowed location in Debian anyway. I'm not sure about if it is allowed or not, but it is the only possible way to ship cross toolchains like in all releases since 2015 - https://tracker.debian.org/news/685686/accepted-cross-toolchain-base-2-source-all-into-unstable-unstable/ I think we (all the toolchainy people in debian & ubuntu, which is like doko xnox helmut and whoever else) agreed to do it this way back in Debconf in Swiss alps by the lake?! or like cambridge mini-debconf?! It's ok if you don't want to integrate `linux-libc-dev-cross` into src:linux I can upload that into debian as a standalone src:linux-libc-dev-cross under the toolchain-base maintainers hat that will build-depend on linux-source and build it for all possible triplets under the sun. And i think we override the lintian warnings there. Because it will be easier to have that once, rather than in all three cross-toolchain-base packages. And it can be updated, without rebuilding the cross-toolchains themselves. Because it is wasteful to acutally do cross toolchains bootstraps just to bump a stable point release of linux headers that like changes nothing. Or just integrate it into src:linux build too, given all of those cross headers are established packages since 2015. (and yes using GNU tripplet as a top level dir) > > > Separately for Ubuntu, due to the number of kernel built, I would likely > > want to upload source package that produces linux-libc-dev as a separate > > source package such that linux-libc-dev is actually only updated when > > needed, rather than on every kernel upload. As there is no need to rev > > linux-libc-dev as often as kernel uploads are done. > > The question here is: does it provide an advantage to have it as > separate source? Less updates IMHO do not count, as they don't come > with a penalty attached. But I see the downside of fixing the user > space API to a different version then the kernel you actually ship in > the end. > Fixing to a different (or sooner) API before kernels actually are ready is one angle that helps Ubuntu. Separately in Ubuntu we have like 16+ custom/customer kernels (i.e. src:linux-acme) and they all keep trying to filter ubuntu repos and build what they need and get confused when they need to build generic kernel and their custom kernel, and constantly try to build linux-libc-dev & linux-source out of their custom kernel and that has conflicts and API level missmatched (in cases when custom kernel is ahead or behind the given Ubuntu's release "baseline" API). Hence for me it will be easier in Ubuntu-only to maintain src:linux that only build generic kernel flavour; and src:linux-uapi builds "stable API" headers and toolchainy things. And it will simplify filtered archives / installs too, of having src:linux-$customer + src:linux-uapi to cover their needs. Speed & frequency of updates matters too, as linux-libc-dev forms part of the toolchain / buildinfo, and for cases were reproducible builds matter, having less churn of linux-libc-dev helps a lot with having stable toolchain version numbers. Also headers change a lot slower, than underlying kernel. But that's a very niche thing (matters for minimising reproducible rebuilds, buildd chroot refreshes, containers that are used as buildds and the like). -- okurrr, Dimitri
