Hi,
I have solved the issue for me. I decided to stick to the most
conservative approach of one fully fledged source package per kernel
flavor and will solve the issue of wasted disk space on both the
internal archive host and on the publicly visible download server with
offline deduplication on the filesystem level. I think I will use btrfs
on the internal archive host and XFS on the download server to get
familiar with both methods, albeit similar. Zugschlus' leftover plate
("Resterampe") of packages that noone wants will probably grow by one in
this process as I have started the salvaging process for duperemove
(which can thankfully both handle XFS and btrfs).
Of the suggestions I received the idea of having a
linux-zugschlus-source binary package that the flavor packages could
build-depend on the most enticing. I still decided to go a different way
since I didn't have so much time to spend. I wrote a python program (>
1000 lines *cough*) that builds the source packages using big parts of
what upstream (and Wichert) have in scripts/packages, generating new
stuff, including glue code to handle the kernel configuration files,
updates, etc, and orchestrates the build of the four source packages and
the respective binaries.
I decided against using Debian's src:linux because the packaging is WAY
more complicated (and harder to understand) that I'll ever need, and I
am usually faster in deploying new stable kernel releases than Debian
is.
Build profiles I thankfully didn't need since the upstream packaging
already fiddles around with the control file to control the creation of
kernel headers, linux-libc6-dev and debug packages. It is an interesting
concept but I'd rather take more time to understand it, and first use it
the way it was intended to be used.
My original idea of having one orig.tar.gz for more than one source
package wouldn't work because that use case is not supposed by
dpkg-source: the orig.tar.gz always must have the same base name as the
source package (even multiple source tarballs have to share the same
prefix), hence I would need multiple, different, but identically named
source packages which you can't put in an archive. That was a stupid
idea of mine and I shouldn't have bothered you with that.
The most obvious but also time-consuming takeway was that you need to
have ARCH and KBUILD_DEBARCH correctly set even for the
{old,n,menu}config step or you will end up with a non-working kernel
that will miss all parts specific to the target architecture when
cross-building.
What I still don't really know is how to handle the linux-libc-dev
package which doesn't have its name versioned and will therefore be
built non-identically, but identically named, by every flavor, doubling
the package name in the archive which doesn't make dak happy. I decided
to only build that package from one of my flavors.
With the current results I can work for the time being. I might
simplify the packaging at some future time (build profiles might
actually help here, making the debian/rules way simpler than the one
that comes with the kernel).
Thank you all for trying to help.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
