Open Stack

On 11/26/2015 05:31 PM, Robert Collins wrote:
> On 27 November 2015 at 03:50, Thomas Goirand <zigo at debian.org> wrote:
>> Hi,
>>
>> As a package maintainer, I'm seeing more and more circular
>> build-dependency. The latest of them is between oslotest and oslo.config
>> in Mitaka.

The situation with oslotest is even more annoying than what I just
wrote: it needs os-client-config, debtcollector, on top of oslo.config
which I wrote above. All of them need oslotest to build.

>> There's been some added between unittest2, linecache2 and traceback2
>> too, which are now really broadly used.
>>
>> The only way I can work around this type of issue is to temporarily
>> disable the unit tests (or allow them to fail), build both packages, and
>> revert the unit tests tweaks. That's both annoying and frustrating to do.
>>
>> What can we do so that it doesn't constantly happen again and again?
>> It's a huge pain for downstream package maintainers and distros.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
> 
> Firstly, as Thierry says, we're not well equipped to stop things
> happening without tests, its the nature of a multi-thousand developer
> structure.
> 
> Secondly, the cases you site are not circular build dependencies: they
> are circular test dependencies, which are not the same thing.
> 
> I realise that the Debian and RPM tooling around this has historically
> been weak, but its improving -
> https://wiki.debian.org/DebianBootstrap#Circular_dependencies.2Fstaged_builds
> - covers the current state of the art, and should, AIUI, entirely
> address your needs: you do one build that is just a pure build with no
> tests-during-build-time, then when the build phase of everything is
> covered, a second stage 'normal' build that includes tests.
> 
> -Rob

Robert,

I'm well aware that this is circular test dependencies. Though not only:
it also impacts sphinx docs.

At the current moment, it's not easy at all to bootstrap a new release
of OpenStack without cheating (ie: picking some already built
dependencies from the past releases).

Yes, I can work around all of these. The thing is, I would prefer if
these were optional by skipping tests if the dependency wasn't present,
because it is very time consuming. So if something could be done
upstream to mitigate as much as possible this problem, instead of just
completely ignoring it, it would be really nice.

So, the answer of Thierry is: we should test for it. The question is,
how? I saw some build dependency graphs done with graphviz. How are they
produced? That would be a good starting point to know what's the current
state of things.

Cheers,

Thomas Goirand (zigo)