Re: Package notes feature causing build paths to be embedded

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, 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.

-- 
Iñaki Úcar
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux