Re: consolidate linux-libc-dev headers
On Thu, 16 Nov 2023 at 19:30, Bastian Blank <waldi@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
Reply to: