Currently in both Debian and Ubuntu we ship like close to 40 .deb packages
that have linux-libc-dev (for native/multiarch, cross, ports, mipses).
Each one of them is like 1.5MB, however they actually all have the same and repeated content.
the bulk of headers are the same on all arches (and enforced via multi-arch:same), asm-generic is also the same for all of them, and then kernel-arch asm headers are unique - but only for given kernel arches (not
all of the debian arch names).
Currently there are only 13 kernel archs for unique asm-arch headers, but
in Debian we have multiple reuses of the same kernel archs with different userspace abi properties (arm = armel armhf, mips = 12 mips archs, powerpc
= 4, x86 = 3, and so on).
It seems wasteful on disk, build-time, and derivative build time to package
all of these separately. Especially since there is a chain of src:linux building native ones + linux-source as a .deb; which is then used by cross-toolchain-base{,-ports,-mips} to unpack and rebuild linux headers
again, and publish. When in practice src:linux itself could build an
efficient libc-dev packages for all arches as an arch:all package and Multi-Arch:foreign.
I have implemented example packaging of that as a standalone source package
https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/
The linux-libc-dev is native & multiarch uapi headers for all arches. The linux-libc-dev-alpha-cross is all debian arch crosses. It is implemented
using hardlinks to maintain all the same paths that are currently being
used by all the arch:any linux-libc-dev packages, and the linux-libc-dev-*-cross packages. In total they provide equivalent
functionality as 40+ linux-libc-dev* current debs in either Debian or
Ubuntu.
Is this something that the debian kernel team could consider supporting / building as either standalone source package, or out of src:linux directly?
as this would reduce 40+ .deb duplication in the mirror pools of the same content; and will eliminate build-depends on linux-source (and thus built-using) from src:cross-toolchain-base* and will actually ensure that
all kernel headers for native / multiarch / cross arches are updated simultaneously, without need to wait for all arch:any builds to catch up
first. It also gives ability to trivially create freestanding toolchains to
any of the arches without actually building a full debian port for or
having a working kernel for a given port.
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.
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. But I do hope to see if this approach for linux-libc-dev can be coordinated to ensure compatible cross-toolchain-base changes.
--
okurrr,
Dimitri
<div dir="ltr">Currently in both Debian and Ubuntu we ship like close to 40 .deb packages that have linux-libc-dev (for native/multiarch, cross, ports, mipses).<div><br></div><div>Each one of them is like 1.5MB, however they actually all have the same
and repeated content.</div><div><br></div><div>the bulk of headers are the same on all arches (and enforced via multi-arch:same), asm-generic is also the same for all of them, and then kernel-arch asm headers are unique - but only for given kernel arches
(not all of the debian arch names).</div><div><br></div><div>Currently there are only 13 kernel archs for unique asm-arch headers, but in Debian we have multiple reuses of the same kernel archs with different userspace abi properties (arm = armel
armhf, mips = 12 mips archs, powerpc = 4, x86 = 3, and so on).</div><div><br></div><div>It seems wasteful on disk, build-time, and derivative build time to package all of these separately. Especially since there is a chain of src:linux building native
ones + linux-source as a .deb; which is then used by cross-toolchain-base{,-ports,-mips} to unpack and rebuild linux headers again, and publish. When in practice src:linux itself could build an efficient libc-dev packages for all arches as an arch:all
package and Multi-Arch:foreign.</div><div><br></div><div>I have implemented example packaging of that as a standalone source package <a href="
https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/">https://ppa.launchpadcontent.net/
xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/</a></div><div><br></div><div>The linux-libc-dev is native & multiarch uapi headers for all arches. The linux-libc-dev-alpha-cross is all debian arch crosses. It is implemented using hardlinks to maintain
all the same paths that are currently being used by all the arch:any linux-libc-dev packages, and the linux-libc-dev-*-cross packages. In total they provide equivalent functionality as 40+ linux-libc-dev* current debs in either Debian or Ubuntu.</div><
<br></div><div>Is this something that the debian kernel team could consider supporting / building as either standalone source package, or out of src:linux directly? as this would reduce 40+ .deb duplication in the mirror pools of the same content;
and will eliminate build-depends on linux-source (and thus built-using) from src:cross-toolchain-base* and will actually ensure that all kernel headers for native / multiarch / cross arches are updated simultaneously, without need to wait for all arch:
any builds to catch up first. It also gives ability to trivially create freestanding toolchains to any of the arches without actually building a full debian port for or having a working kernel for a given port.</div><div><br></div><div>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.</div><div><br><
/div><div>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. But I do hope to see if this approach for linux-libc-dev can be coordinated to ensure compatible cross-toolchain-base changes.</div><div><div><div><br></div><
span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>okurrr,</div><div><br></div><div>Dimitri<br></div></div></div></div></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)