On Tue, 2020-01-21 at 13:33 -0500, Steve Grubb wrote: > On Tuesday, January 21, 2020 1:16:00 PM EST Miro Hrončok wrote: > > > > > > I proposed a change to redhat-rpm-config to handle this case by > > > > > > > > > > allowing package to add a single line to their .spec file to turn off > > > > > the new common symbol handling. Igor rejected that change arguing that > > > > > the packages themselves should be fixed. > > > > > > > > Ultimately yes they should be fixed, but giving a means of easily > > > > mitigating the problem while people work with upstream to fix the > > > > issues is also useful, it's been a problem for ever and expecting > > > > people to fix it in short order is problematic especially when they'll > > > > start to be deluged in FTBFS spam within moments of the mass rebuild. > > > > > > That was the idea. Provide a trivial opt-out so that upstreams had > > > time to fix properly. I even volunteered to add the opt-out marker > > > where appropriate to minimize the FTBFS issues. I also volunteered to > > > help with the packages that don't honor flags injection. > > > > This sounds reasonable to me. > > > > The PR is > > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77 > > > > I have reopened it. > > > > The mass rebuild will notify the maintainrs and they can use that macro to > > short-workaround the problem. It' also easier to grep from the specs than > > custom patches and whatnots > > I need something like this for suricata. It has about 45 variables causing > this. And it's not a simple "extern" addition because it looks like in many > cases the variable was never placed in a C file. Simply adding extern keyword > leads undefined reference errors. This will take a while to sort out with > upstream. You also have to be careful if you're building shared libraries -- I was looking at a package (I forget which) which built multiple DSOs. If you're not careful you can end up with some DSOs which wouldn't have the definition -- worse yet, you're not going to get an undefined symbol when you build those DSOs. jeff _______________________________________________ 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
