This discussion is still active on the mailing list, so I'm going to put a placeholder -1 here to avoid auto-approval. I'm also going to exclude it from today's meeting due to the ongoing discussion.

I think in order to do this, we (meaning FESCO) need to at least decide and document the multilib use cases that we want to support in Fedora and ideally also add CI tests for these use cases.

@decathorpe If you could just update the proposal to make the intentions clear, I'd happily +1 it.

I think in order to do this, we (meaning FESCO) need to at least decide and document the multilib use cases that we want to support in Fedora and ideally also add CI tests for these use cases.

I disagree. We allow maintainers to drop leaves. If dropping a leaf breaks the multilib use case, clearly the maintainer was not interested in supporting the multilib use case and we had a problem anyway. Unless there is a very fast chain response of massively dropping new leaves (which is unlikely), we have an easy way to fix that (and a hard way to figure out how to maintain the i686 version of that package without bothering the maintainer who was not interested).

As for CI, we hardly test much more important things than multilib in the CI. Making it a requirement is not fair.

If you could just update the proposal to make the intentions clear, I'd happily +1 it.

At this point, I am rather befuddled how people can continue to misinterpret my intentions with this proposal. Maybe swapping out "Encourage" with "Simplify" in the proposal title could help? ... Other than that, I think I already incorporated almost all suggestions I got for making it more clear.

I think in order to do this, we (meaning FESCO) need to at least decide and document the multilib use cases that we want to support in Fedora and ideally also add CI tests for these use cases.

I also agree that this is a disproportionately high hurdle to clear for a proposal with very limited scope and impact. That said, I'm still working a program that will tell packagers "YES, you can add ExcludeArch: i686 to this package" or "NO: your package is still depended on by foo.i686 / is a dependency of steam / wine / etc.", which should help to avoid accidental non-leaf-package removals.

If you could just update the proposal to make the intentions clear, I'd happily +1 it.

At this point, I am rather befuddled how people can continue to misinterpret my intentions with this proposal. Maybe swapping out "Encourage" with "Simplify" in the proposal title could help? ... Other than that, I think I already incorporated almost all suggestions I got for making it more clear.

Oh, so I've probably missed this update:

https://fedoraproject.org/w/index.php?title=Changes%2FEncourageI686LeafRemoval&type=revision&diff=637828&oldid=637503

Consider me +1

+1 too

I hope we can take this further, but it's a good start anyway.

I think in order to do this, we (meaning FESCO) need to at least decide and document the multilib use cases that we want to support in Fedora and ideally also add CI tests for these use cases.

I disagree. We allow maintainers to drop leaves. If dropping a leaf breaks the multilib use case, clearly the maintainer was not interested in supporting the multilib use case and we had a problem anyway. Unless there is a very fast chain response of massively dropping new leaves (which is unlikely), we have an easy way to fix that (and a hard way to figure out how to maintain the i686 version of that package without bothering the maintainer who was not interested).

The problem is that we don't even know what the multilib use cases are, and even if we did, we have no way to tell if they are actual working. So, it's not quite a simple as: Package gets dropped, Use case breaks then we fix it. We may not find out something is broken until it's too late.

I do agree that this policy is not necessarily creating new problems, it's just making the existing problems more obvious and that this is a probably too much to ask of the change owners for this specific proposal. We still have more work to do in this area, but I think we are moving in the right direction with the recent devel thread polling users on what use cases they want.

@tstellar would you be happier if I added and compiled the list of multilib packages that we (currently) need to keep for the most common use cases that were mentioned on the devel list?

(i.e. primarily "which .i686 packages are pulled in when installing wine and / or steam on x68_64")

@decathorpe I think that would be great.

I've added a list of source packages that will need to continue building for i686 to support wine and steam use cases. This list is not complete (it does not cover everything we need built on i686, for example, recursive BuildRequires are not considered). But we need at least those packages to continue supporting common use cases.

FTR, I'm also +1 to my own proposal.

@sgallagh Still -1?

I'm +1 now.

@decathorpe Have you considered creating a view and workflows on https://tiny.distro.builders/ to track down the dependencies? It's what it's designed to do.

@sgallagh I have not. How does that work? I've never interacted with that tool before (other than failing to understand why some of my packages are included in ELN). Can I just tell it "everything required by steam.i686 and wine.x86_64?

APPROVED (+4,0,-0)

Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/6V5UX33T2WYUNQZRV3BCYIPDGIVABSI6/