Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Quoting Simon McVittie (2013-03-05 16:54:00)
> On 05/03/13 11:22, Johannes Schauer wrote:
> > Since self-cycles in Debian are often unintuitive, maintainers might be unaware
> > that the source packages they maintain are actually forming a self cycle.
> This is useful information. Is there any way in which the maintainers of
> these packages can say "yes, we know, and here is where you break the
> cycle" without using unmerged dpkg features or breaking the freeze?
Actually, yes. Here is the full list of things available to the bootstrapper
when encountering a build dependency cycle:
1. Introduce reduced build dependencies
2. Move dependencies from Build-Depends to Build-Depends-Indep
3. Use Multi-Arch:foreign packages to satisfy dependencies
4. Choose different installation sets for not-strong dependencies
5. Split the source package in question
6. Make binary packages available through cross compilation
The first item is obviously not implementable right now. But the second one is!
The third solution depends on the target the bootstrap is done for. The fourth
item is of no concern for this type of cycle. The fifth one is implementable
right now. The sixth is always the last resort.
So it is possible right now for maintainers to say "yes, we know, and here is
where you break the cycle" without using unmerged dpkg features or breaking the
freeze by either
2. moving the dependency to Build-Depends-Indep (if the build dependency only
builds Architecture:all packages) or
5. by splitting the source package into two
I was reminded of the option to split a source package by bug#702620  which
splits colord-gtk from colord. Just note that splitting might not always be
sensible as cycles might simply vanish once some dependencies of binary
packages in the dependency chain change. Though in this case one can probably
be sure that libgtk-3-0 will always depend on libcolord1?