On 18/07/2025 21:28, Ahmad Khalifa wrote:
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.
On second thought, if it's not a package, a shell script with a few
lines could do this for you.
Still relying on kbuild's -O argument, but basically something like:
for b in build-server build-vm ...; do
mkdir $b
make -O $b mrproper
cp config-for-server-that-I-prepared-already $b/.config
make -O $b olddefconfig
make -O $b vmlinux modules # or whatever you're building
make -O $b deb-pkg # I think
done
Then copy your deb files out.
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
