Am Mon, 13 Mar 2017 17:59:35 +0100 schrieb Dimstar / Dominique Leuenberger :

Just as a comparison: when we switch on rebuildstrategy 'direct' (which is still more optimized than OBS' default): TW churns around usually for 3 - 5 days - definitively too much for Tumbleweed snapshots to be building.

Sometimes I wonder if it is worth having a snapshot every other day instead of having a consistent system every time a snapshot is released. An otherwise idle person might be addicted to the daily snapshot, the rest of the world would most likely be fine with a snapshot every other week. The :Update repo would deal with the CVEs. Also there are pkgs which take way too long to rebuild. If they would be moved to a special extra repo then QA could just check if the currently available binary still works, even if the rebuild in that extra repo is not fully done. Later the binaries from that extra repo could be merged back into the 'oss' install repo to make it transparent.

It's not even clear if the issue would not have appeared, as libffi4 was part of the distro and was readily available to be used - and now it's not any longer

If nothing links against it anymore a full rebuild would have caught it. But perhaps I misunderstood your question. I thought it was about an automated check if the disappeared pkg 'x' is still required by another pkg. A full rebuild, with build-compare reducing the fallout, might be one way of doing that. Olaf

On Monday 2017-03-13 17:45, Olaf Hering wrote:

Am Mon, 13 Mar 2017 17:23:19 +0100 schrieb Dimstar / Dominique Leuenberger :

...

Any ideas are welcome on how to avoid this in the future - the more automatic it is, the higher the chance of it not failing again.

[...] I think ABI breakage happened often enough in the past to consider a change [to full rebuilds].

The nasty ones are the ABI breaks without notice. Like, when libglib adds a symbol and does not update its -Wl,--version-script. (like it currently does - it has none at all). But libffi4 vs libffi7 is something that could, methinks, be determined apriori, since the SO name is changing, we know that there is a cut and need to rebuild. Isn't that already how it works, anyway? And since we know there is a cut.. such DRs could be delayed by infrastructure automatically. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org