On 18/07/2025 21:16, Marc Haber wrote:
Hi,
I would like to re-work my linux kernel building process and would like
to do it right this time: Build a clean source package that dak and
sbuild will accept. I do not plan to upload this to Debian, but I think
that we all can learn from some discussion.
I would like to build differnt "flavors", lets call them linux-server,
linux-vm, linux-desktop and linux-notebook. But I'd like to have them
from - at least - the same .orig.tar.gz, just for the reason that this
file is about 150 MB large.
So my idea would be:
linux-6.4.15.orig.tar.gz
linux-6.4.15-server_6.4.15-1.debian.tar.gz
linux-6.5.14-server_6.4.15-1.dsc
linux-6.4.15-vm_6.4.15-1.debian.tar.gz
linux-6.5.14-vm_6.4.15-1.dsc
linux-6.4.15-desktop_6.4.15-1.debian.tar.gz
linux-6.5.14-desktop_6.4.15-1.dsc
linux-6.4.15-notebook_6.4.15-1.debian.tar.gz
linux-6.5.14-notebook_6.4.15-1.dsc
with all those .dscs refering to the same, identical
linux-6.4.15.orig.tar.gz.
The source packages would then build,
linux-image-6.5.14-server_6.4.15-1_amd64.deb
linux-image-6.5.14-vm_6.4.15-1_amd64.deb
linux-image-6.5.14-desktop_6.4.15-1_amd64.deb
linux-image-6.5.14-notebook_6.4.15-1_amd64.deb
and the respective other packages like linux-headers and linux-libc-dev.
Is our tooling able to do this? How would the control file have to look
like?
Imagemagick does a really good job of taking a single source and
producing multiple binary flavours if you take a look at its d/rules
iterating over {q16,q16hdri}.
I believe d/control has to be a static file, but that's ok in your case
as you need the kernel's .config files to match in the first place.
For the kernel, you probably want to place the relevant .config file
first and then use `make -O build-flavourX TARGET' to
configure/build/install multiple binary dirs (e.g. build-server,
build-vm, ...).
There are other packages that do that too, but I'm not familiar with how
e.g. exim, nginx, ...
For the real work, I'd like to make use of the make srcdeb-pkg and make
bindeb-pkg that come with the upstream sources. Those mechanisms were
written bei Wichert 20 years ago but have been (carefully) updated so
that they still work. I would probably have to throw away the source
package that make srcdeb-pkg builds and patch the debian/ directory made
in the process before building "my" source package, but that sounde easy
enough.
Would dpkg's "new" feature of having source packages with more than one
orig.tar.gz work here?
Any ideas?
Greetings from (still) Brest
Marc
--
Regards,
Ahmad