[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: consolidate linux-libc-dev headers



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


Reply to: