Michael Catanzaro wrote:
> Thing is, Kevin has a point here.
You are simulating agreement here, but you are still opposed to the solution
I am actually proposing, so we are still actually in diametral disagreement.
> 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.
Annobin is just a pain by design due to having to be rebuilt for each and
every package update in the toolchain.
> 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....
Both these ideas would not have fixed the race condition between the GCC
update with one annobin rebuild and the LLVM update with another annobin
rebuild. We would just have had two conflicting annobin updates instead of
three, still one too many.
In addition, if bugs come up in the annobin plugin itself, it needs to be
fixed.
> Rebuilding packages makes it much less useful
I still have not seen any convincing argument why, if you are going to
unpack all packages and scan their annobin annotations for "bad" build
flags, it would be any less useful to do this on a side repository with
packages rebuilt with annobin enabled than to do this directly on the main
repository. There is a one-time effort to set up the rebuilding bot, but the
quality of the resulting analysis should be exactly the same. Rebuilding
with annobin enabled will not magically change the GCC flags used to build
the package.
> and increases delta between Fedora and RHEL.
Fedora should be optimized for Fedora users' needs, not for RHEL users'
needs.
> Minimally-increased package size is a silly concern. The problem here is
> just broken updates.
IMHO, both are issues, but I agree that the broken updates are the bigger
issue.
Kevin Kofler
_______________________________________________
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
