On Thu, Jan 27, 2022 at 12:50:33PM +0100, Vít Ondruch wrote: > > 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/110 > >There'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? OCaml is a compiled language, not interpreted. It ships a compiler which embeds CFLAGS / LDFLAGS (for hardening). But additionally it ships many libraries that contain link instructions (so they can link to C libraries), and those also embed LDFLAGS. Just about every OCaml package is negatively affected by this change and they all have to be rebuilt. Rich. > > 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. > > > _______________________________________________ > 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 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ 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
