On 12/11/19 9:23 PM, Helmut Grohne wrote: >> Normally, this is fixed by adding a stage1 sbuild profile for boostrapping >> the package. When building with the stage1 profile, the build dependency >> on python3-scipy should be disabled (i.e. python3-scipy [!stage1]) such that >> the numpy package can be built without scipy. > > I disagree. stage1 usually is the last resort for such situations. It > should not be added lightly. In fact, stage1 has been deprecated as a > profile for this reason. It shouldn't be introduced at all anymore.
Meh, whatever it's called these days. >> Can you add such a stage1 profile so I can bootstrap numpy for all the >> architectures where it's currently BD-Uninstallable? > > Please don't. stage1 is undescriptive and in three years nobody will > know what it was being added for. I don't have a strong opinion on it. If it needs to be called !pkg.bla.foo, I'm fine with that, too. > That said, the BD-Uninstallable situation and the circular dependency > are real and they deserve a solution. Let's try the less heavy > approaches first: > * Maybe scipy is only used for testing numpy or vice versa? Then one > could be annotated <!nocheck> and we'd be done. > * Similarly, maybe one is only needed for building Arch:all packages? > Then maybe it could be demoted to Build-Depends-Indep. With luck > that could also mean we're done. > * If that really doesn't help, we need to figure out how they integrate > with one another. We need to describe the feature that they enable > and add a descriptive profile for disabling that feature. > > So please try <!nocheck> and Build-Depends-Indep before asking for a > profile. These standard measures are regularly tested and have meaning > beyond bootstrapping. Only if that fails, document and understanding for > what features actually cause the cycle and add a profile disabling such > a feature in particular. My main point was notify about this circular dependency problem that should always be resolved because these situations can always occur with packages with circular dependencies. This is why packages like ffmpeg are always rebootstrappable. I haven't looked at the details yet. I normally assume that the maintainer knows which of the two affected packages can be temporarily built with the other. But I can have a look tomorrow. > Thank you. Also thanks for Ccing me. Of course. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
