I think the change owners is wrong ;) That would be me and @ngompa

@ignatenkobrain Oops, I looked at the wrong window. It's corrected now. Thanks!

Most people say that this is safe and has been done in other distributions, but there have been some voices saying that it is risky. Without more information I'll assume that there is some risk. I'm wary of enabling this in between the mass rebuild and release. Before the release we try to stabilize things and only do changes that fix known issues, but this would create a scenario where packages could be rebuilt for the first time with the changed flags late in the game, even during the freeze.

Thus, right now I think we should postpone this until F30. Are there strong arguments to do this sooner?

@jakub indicates on list that: "this option is quite dangerous and breaks a lot of stuff,
ask SUSE people or other distros on how many times they need to add
workarounds for this."

Perhaps we should look at other distros here and see what kind of issues are possible.
It may be that they upstreamed any fixes and we are in better shape, or it might be that they didn't switch to this.

Additionally, you could perhaps setup a copr and do a random selection of packages with this change? or critial packages (python, glibc, kernel, etc).

Just a random example of what breaks with --as-needed: http://gcc.gnu.org/PR84428 .
More generally, anything where the intent is that e.g. a binary or non-dlopened library loads some library that will then be needed by something dlopened, often could be e.g. libpthread. Some libraries have conditional thread support using weak references, but if those libraries are linked with a binary or earlier dlopened library, libpthread might not be loaded at that point, but later on dlopened. This results in those libraries not being thread-safe. If e.g. the main binary is compiled with -pthread or -lpthread, it might work only without --as-needed, but not with that.

@jakub, how often this happens? Many of other distros switched to use this flag many years ago and I expect most of the packages to be fixed.

@kevin, sure! I'm going to build all packages from @build group in COPR repo with this flag.

http://gcc.gnu.org/PR84428

That one is about address sanitizer and --as-needed doesn't appear there. Wrong bug number?

No, the by default added --as-needed is exactly the problem in there, that is why it is a NOTABUG for upstream which doesn't have such a default and those that have such defaults need to add their workarounds.

Oh, OK. The upstream issue https://github.com/google/sanitizers/issues/934 is better explained.
But asan is a special thing that does tricky stuff. Do we have other examples?

As I responded on the mailing list, I'm -1 to this change in F29. It's too late for default flag changes, which we've (FESCo) previously agreed have to be done as part of a mass-rebuild to catch the fallout all at once.

-1 to this Change for F29, but I'd be +1 to seeing it land in Rawhide right after we branch.

We will discuss this in today's meeting, which starts in about an hour in #fedora-meeting-1.

Proposal: approve for F30 (basically as soon as F29 branches out).

Proposal: approve for F30 (basically as soon as F29 branches out).

+1

We were unable to get a consensus about whether to approve this today, and we all seemed to agree that more information would be helpful. In particular, we'd like to be able to have @jakub attend a FESCo meeting where we discuss this, and it was also suggested that it would be helpful to have information about which other distros have done this and/or written documentation about it (positively or negatively).

AGREED: defer this ticket until a future fesco meeting when @jakub can attend to discuss with us (+5, 0, -0)

@jakub, will you be attending tomorrow's meeting?

The change was approved for F30 at today's FESCo meeting.

We expect it to be activated immediately after branching to provide maximum time to shake out issues or invoke the contingency plan.