Support for flavors or multiple builds

Hi Niels,

I learned that you plan to support multiple builds in debputy eventually. Let me use the opportunity to echo some in-person discussions from Debian Reunion Hamburg 2023 on that topic and see how they interact with debputy.

Supporting multiple builds or flavors is a recurring topic and is currently solved in heterogeneous ways. Let me give some examples.

• cmake used to contain the emacs integration, but that was split out to a separate source package emacs-cmake-mode drawing from the same source and now updated in lock-step with cmake. The main motivation was improving testing migration of cmake by getting rid of the emacs interaction.
• curl performs multiple builds for different TLS libraries. Notably, curl varies the applied patches per build.
• unbound provides a library and a server. These can be built independently from the same source. A build profile has been added to help bootstrapping. openldap and `elfutilsis are split in a similar way.
• Quite a number of packages include perl, python or ruby bindings. Often times those are packages separately with separate instructions and are also separated by build profiles noperl, nopython or noruby. These tend to be dependent on the "main" build though.
• systemd and a few other packages include a separate pass for udebs.
• cross-toolchain-base, gcc-N-cross and gcc-xtensa-lx106 are effectively splits of gcc-N as they all build depend on gcc-N-source. There also is binutils-source, glibc-source and a few more.

There are quite different requirements for these examples. Let my try to establish some patterns.

• Performing multiple builds of the same source with varying configuration and sometimes varying dependencies.
• Performing multiple builds in different parts of the source tree sometimes depending on one another.
• Reducing Build-Depends to ease testing migration.
• Reducing Build-Depends to ease bootstrapping.
• Reducing the size and duration of builds.

I'm not sure how debputy fits in here. Supporting these use cases in a more general form requires changes to the archive. The ideas I've seen thus far include:

• One way is embracing build dependencies on source packages. Doing so would make it easier to split source packages. This still poses quite a bit of duplication in debian/rules and other places though.
• Another way is partitioning source packages using build profiles. In order to make this really useful, the archive would have to build a source package multiple times per architecture and learn which build profiles to pass. Additionally, the autoremover has to be able to remove a partition (build profile) from a source package.

The scope of this definitely is wider, but maybe debputy is part of the solution here. In case the discussion does not yield anything useful, don't hesitate to close the issue as "not actionable".