Open Stack

On 08/25/2015 11:20 PM, Robert Collins wrote:
>> This first happened with PBR. Kilo can't use >= 1.x
> 
> This is due to Kilo having *inappropriate* version caps on its
> dependencies. Which we've been busy unwinding and fixing
> infrastructure this cycle to avoid having it happen again on Liberty.

Thanks for doing this. I've seen *many* occurrences of what you call
"defensive dependencies" which I had a hard time dealing with.

>> , and Liberty can't
>> use <= 1.x.
> 
> This is because pbr 1.x offers features that Liberty needs. Thats how
> software moves forward: you add the feature, and someone else uses it
> and declares a dependency on your version.

Sure, no problem with this.

>> So I can't upload PBR 1.3.0 to Sid. This has been dealt with
>> because I am the maintainer of PBR, but really, it shouldn't have
>> happen. How come for years, upgrading PBR always worked, and suddenly,
>> when you start contributing to it, it breaks backward compat? I'm having
>> a hard time to understand what's the need to break something which
>> worked perfectly for so long. I'd appreciate more details.
> 
> More of the ad hominens.

Robert, I'm sorry you take it this way. Sure, I was kind of frustrated
to see all the added work I have for dealing with issues with the newer
mock. Though I was writing to you directly as we know each other for a
long time. I didn't intend this as an attack.

> As I say above, its not a PBR problem. Its badly expressed defensive
> dependencies in kilo's runtime requirements. Fix that, and kilo will
> be happy with newer pbr.

That'd be too much work to patch all of kilo's requirements.txt
everywhere, I'm afraid I prefer to leave things as they are.

>> But for mock, that's another story. I'm not the maintainer, and the one
>> who is, decided it was a good moment to upload to Sid. The result is 9
>> FTBFS (failures to build from source) so far, because mock >= 1.1 is
>> incompatible with Kilo (but does work well with Liberty, which
>> *requires* it).
> 
> Yes, Liberty requires it because we're porting to Python3.4 and up,
> and mock < 1.1 is incompatible with Python3.4.

Oh !!!

>> Anyway, the result is that mock 1.3 broke 9 packages at least in Kilo,
>> currently in Sid [1]. Maybe, as packages gets rebuilt, I'll get more bug
>> reports. This really, is a depressing situation. Now, as the package
>> maintainer for the failed packages, I have 4 solutions:
>>
>> 1/ Reassign these bugs to python-mock.
>> 2/ Remove all of the unit tests which are currently failing because of
>> the new python-mock version. This isn't great, but as I already ran
>> these tests with mock 1.0.1, it should be ok.
>> 3/ Completely remove unit tests for these Kilo packages (or at least
>> allow them to fail).
>> 4/ See what's been done in Liberty to fix these tests with the newer
>> version of mock, and backport that to Kilo.
> 
> 5/ update OpenStack in unstable to be Liberty

This isn't an option: I haven't tested Liberty b2 enough, and b3 is soon
out. I prefer to upload to Sid whatever is the latest stable, meaning I
prefer to keep Liberty in Experimental until the final release, and
leave the stable Kilo in Sid.

> 6/ Build something in Debian to deal with  conflicting APIs of Python
> packages - we can do it with C ABIs (and do, all the time), but
> there's no infrastructure for doing it with Python. If we had that
> then Debian Python maintainers could treat this as a graceful
> transition rather than an awkward big-bang.

Even if we had such a thing (which would be great), we'd still have to
deal with transitions the way it's done in C, which is hugely painful.

>> Unfortunately, 4/ isn't practical, because I'm also maintaining
>> backports to Jessie, which means I'd have to write fixes so that the
>> packages would work for both mock 1.0.1 and 1.3, plus it would take a
>> very large amount of my time in a non-useful way (I know the package
>> works as it passed unit tests with 1.0.1, so just fixing the tests is
>> useless).
> 
> One can't actually know that. Because one of the bugs in 1.0.1 is that
> many assertions appear to work even though they don't exist: tests are
> ilently broken with mock 1.0.1.

FYI, I'm going for the option of not running the failed tests because of
what you're explaining just above.

>> So I'm left with either option 2/ and 3/. But really, I'd have preferred
>> if mock didn't break things... :/
>>
>> Now, the most annoying one is with testtools (ie: #796542). I'd
>> appreciate having help on that one.
> 
> Twisted's latest releases moved a private symbol that testtools 
> unfortunately depends on.
> https://github.com/testing-cabal/testtools/pull/149 - and I just
> noticed now that Colin has added the test matrix we need, so we can
> merge this and get a release out this week.

Hum... this is for the latest testtools, right? Could you help me with
fixing testtools 0.9.39 in Sid, so that Kilo can continue to build
there? Or is this too much work?

>> I hope the message is heard and that it wont happen again.
> 
> I certainly hope we won't have an email thread like this again :)

Well, if I get a flood of failure to build bugs because of API breakage,
I probably will be tempted to start a thread about it, but I'll try to
be more careful when choosing my words. Hopefully, no more breakage will
be needed.

Cheers,

Thomas Goirand (zigo)