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 theemacs
integration, but that was split out to a separate source packageemacs-cmake-mode
drawing from the same source and now updated in lock-step with cmake. The main motivation was improving testing migration ofcmake
by getting rid of theemacs
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
orruby
bindings. Often times those are packages separately with separate instructions and are also separated by build profilesnoperl
,nopython
ornoruby
. These tend to be dependent on the "main" build though. -
systemd
and a few other packages include a separate pass forudeb
s. -
cross-toolchain-base
,gcc-N-cross
andgcc-xtensa-lx106
are effectively splits ofgcc-N
as they all build depend ongcc-N-source
. There also isbinutils-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".