<div dir="ltr">Neither Debian not Fedora rebuild dependencies, you'll see a lot of "rebuild" changelog entries where API changes demanded it to happen.<div><br></div><div>Our builds take longer but you know the build always works. Their builds may be broken without anyone noticing for a while.</div><div><br></div><div>Ross</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 July 2017 at 11:18, Alexander Kanavin <span dir="ltr"><<a href="mailto:alexander.kanavin@linux.intel.com" target="_blank">alexander.kanavin@linux.intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/31/2017 12:53 PM, Alexander Kanavin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The only thing I found was this email:<br>
<a href="http://lists.gnu.org/archive/html/bug-gperf/2017-01/msg00004.html" rel="noreferrer" target="_blank">http://lists.gnu.org/archive/h<wbr>tml/bug-gperf/2017-01/msg00004<wbr>.html</a><br>
which was ignored by upstream.<br>
<br>
However, both debian testing and fedora rawhide have gperf 3.1, so I'm not sure how they made it work. I'm running debian here, so can look into this.<br>
</blockquote>
<br></span>
Right. Debian dropped the updated gperf package into repositories, but did not rebuild anything that relies on it. When I tried that with libcap, I got the exact same error as we've seen.<br>
<br>
Not sure what's going to happen when they discover the incompatibility. I'm a bit surprised they don't do such dependency rebuilds when changes are introduced.<br>
<br>
Alex<br>
</blockquote></div><br></div>