On Thu, Apr 14 2022 at 03:02:16 AM +0200, Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Given that this is not the first time that we have annobin-induced
breakage
endangering a release,
Thing is, Kevin has a point here. I've lost track of the number of
times annobin troubles have resulted in gratuitous toolchain breakage.
Sure seems like this happens more than it should.
It probably is time to consider special rules for this package. Perhaps
annobin should not be updated unless both GCC and LLVM are also updated
in the same bodhi update? Or, if this is difficult for some reason,
maybe annobin should only be updated in rawhide and not in branched
releases? Just brainstorming....
I really have to wonder why we insist on shipping
this debugging tool by default for production builds. I understand
that the
security team wants to analyze the annotations to, e.g., detect
packages
built with insecure flags, but I do not see why that analysis needs
to be
done on the official binary packages, i.e., why the packages cannot
just
(for that analysis) be rebuilt with annobin enabled on a private
system that
does not expose the entire community to the fragility of annobin (and
the
increased package sizes due to the annotations).
Rebuilding packages makes it much less useful and increases delta
between Fedora and RHEL. Minimally-increased package size is a silly
concern. The problem here is just broken updates.
Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
