Dne 27. 01. 22 v 12:18 Iñaki Ucar napsal(a):
On Thu, 27 Jan 2022 at 12:09, Vít Ondruch <vondruch@xxxxxxxxxx> wrote:Dne 27. 01. 22 v 11:19 Iñaki Ucar napsal(a):On Thu, 27 Jan 2022 at 10:58, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:I think this change should be reverted until a cleaner way can be found to implement it.I'm all for making better, but please make concrete proposals.Here's a concrete proposal: - Copy %build_*flags to another private macro, let's say %_build_*flags. - Add there the stuff that is not valid once the current build finishes (e.g., the flag that this change adds). - Use that in %set_build_flags and leave %build_*flags as it was.That sounds similar to "%extension_cflags/%extension_cxxflags/%extension_ldflags" Zbyszek already mentioned elsewhere. Or I don't get the point. Here is concrete proposal for Ruby: https://src.fedoraproject.org/rpms/ruby/pull-request/110There's a *big* difference: switching to %extension_*flags means that many packages have to be modified
But why? In Ruby, it should be enough to change Ruby itself and all the other Ruby packages should be fine. Why is it different for R/OCAML?
Vít
, and we have to ensure that stuff does not end up in places like pkgconfig files. This is not discussed in the change proposal. Are proposal owners willing to do that work? Instead, what I propose leaves %build_*flags as they are, so there should be no impact. Still, proposal owners would need to identify which packages are currently broken and rebuild them. And then there are other minor differences: - Are %extension_*flags present in EPEL? - Do we really want to remove hardening flags from extensions? Why should we have a different standard for them? Apparently they caused trouble in the past in Python packages. Not sure what kind of trouble, but we have no issues in the R ecosystem, for example. And I suspect other ecosystems do not either, since they are using %build_*flags and not extension flags.
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
