> 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) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
