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