On Tue, Jan 03, 2017 at 08:08:32AM -0000, Lukas Slebodnik wrote:
But there is nothing that can be done about it. The symbol versions come
from upstream, every release that adds new symbols adds new symbol version,
and we do want to test glibc before it is released, we can't just wait until
it is released and then push it into the distro, hoping other distros have tested
it. Adding a symbol version for each set of symbols added together would be
major change for upstream, one that would have severe runtime implications,
and also effectively require that as soon as you add something you've done
everything right, no further changes to the API are possible. While in the
current development model, until glibc is released, there is still time to
fix stuff up, remove symbols again (doesn't happen often) etc.
That's the reason why i mention (in different mail) to rename unreleased
version to some snapshot.
GLIBC_2.25 - > GLIBC_2.25_unreleased_$num
It would solve the problem because packages would either require GLIBC_2.25_unreleased_1
or GLIBC_2.25_unreleased_2. In the first case, they would need to be rebuild against the
latest glibc. And people could not hit such bugs as 1409557 or 1409590.
But I can see that neither Florian nor you like such idea. Therefore it would be very good
to at least rebuild images(docker, cloud, maybe module in future) after adding adding new
symbols to glibc in rawhide.
I wrote in different mail that it does not happen very often (3 times in 26 minir releases
so far for fedora 26)