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.
Actually I cannot find this anywhere yet - is this something you only have locally so far, or has it been pushed anywhere in a git repo, pull request or anything? > > > 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. > > > 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. > > > 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. > > Regards, > Bastian > > -- > Knowledge, sir, should be free to all! > -- Harry Mudd, "I, Mudd", stardate 4513.3 > -- okurrr, Dimitri
