On Mon, Mar 06, 2017 at 01:27:14PM -0000, Sebastian Marsching wrote:
> I guess there is only one case where the current "fix" would help. If
> someone had some library providing libungif in a different place, the
> broken symlinks in /usr/lib might take precedence, thus hiding the
> correct files.
Do we know if anyone has reported this case?
> In my opinion, removing the dangling symlinks is a slight improvement on
> the current situation and the risk of breaking something is very low. On
> the hand, I do not know whethere there are other considerations
> regarding a SRU in addition to the potential for regressions (which is
> low in this case).
The risk may be low but it is non-zero. If we don't know of any user
impacted, I don't think there is any justification for an SRU.
> Sure, it's low priority but the fix isn't wrong.
Sure, but that's something for the development release. In the stable
release, I think we need a better reason (such as non-hypothetical
affected users).
On Mon, Mar 06, 2017 at 01:27:14PM -0000, Sebastian Marsching wrote:
> I guess there is only one case where the current "fix" would help. If
> someone had some library providing libungif in a different place, the
> broken symlinks in /usr/lib might take precedence, thus hiding the
> correct files.
Do we know if anyone has reported this case?
> In my opinion, removing the dangling symlinks is a slight improvement on
> the current situation and the risk of breaking something is very low. On
> the hand, I do not know whethere there are other considerations
> regarding a SRU in addition to the potential for regressions (which is
> low in this case).
The risk may be low but it is non-zero. If we don't know of any user
impacted, I don't think there is any justification for an SRU.
> Sure, it's low priority but the fix isn't wrong.
Sure, but that's something for the development release. In the stable
release, I think we need a better reason (such as non-hypothetical
affected users).