Do we need a change proposal for this?

[Bob Mauchin]

Hello everyone,

So, I and some Go fellows would like to drop i686 from Go supported arches
(not for go itself but the libraries and binaries we build with it).

Since technically Fedora isn't proposing the i686 variant to download
anymore, does it make sense to need a change proposal? No-one would
technically be impacted, except us who wouldn't have to deal with int
overflows.

If possible we'd like to kick this into action before our mass rebuild.

Best regards,

Robert-André

[Ben Beasley]

Since [1] was approved, I think you would not need a Change proposal as long as dropping i686 truly would not impact other packages.

If anything depends on any of the packages you want to change, then you would need to figure out the full dependency tree and work in from the leaves, convincing those maintainers to drop i686 before doing so yourself.

If there are dependent packages and it isn’t possible to get them to drop i686 first, that’s when you would need a Change proposal; [2] is an example of that.

[1] https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
[2] https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs

On Sat, Jul 2, 2022, at 4:48 AM, Bob Mauchin wrote:
> Hello everyone,
>
> So, I and some Go fellows would like to drop i686 from Go supported 
> arches (not for go itself but the libraries and binaries we build with 
> it).
>
> Since technically Fedora isn't proposing the i686 variant to download 
> anymore, does it make sense to need a change proposal? No-one would 
> technically be impacted, except us who wouldn't have to deal with int 
> overflows.
>
> If possible we'd like to kick this into action before our mass rebuild.
>
> Best regards,
>
> Robert-André
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

[Fabio Valentini]

On Sat, Jul 2, 2022 at 1:57 PM Ben Beasley  wrote:
> Since [1] was approved, I think you would not need a Change proposal as long as dropping i686 truly would not impact other packages.
>
> If anything depends on any of the packages you want to change, then you would need to figure out the full dependency tree and work in from the leaves, convincing those maintainers to drop i686 before doing so yourself.
>
> If there are dependent packages and it isn’t possible to get them to drop i686 first, that’s when you would need a Change proposal; [2] is an example of that.
>
> [1] https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> [2] https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs

Yup, for removing unused packages on i686, you're already set.
You might even say I've done your paperwork for you :)

The only two cases you'd need to take care to look into are:

- Go binaries that are used by non-Go packages.
Those (and all their dependencies) would need to stay, unless those
non-Go packages would also stop building on i686.
This includes both build-time and run-time dependencies.
Or, if the package in question is noarch, you'd need to make sure that
it's not ever built on a i686 build host, and doesn't use the
functionality provided by the Go binary at runtime.

- Go libraries used for building several language bindings for some
other project (I'm thinking of stuff like protobuf):
The Go bindings for provides-multiple-language-bindings packages would
need to be gated behind "%ifnarch %{ix86}".

So, It won't be as simple as just dropping "%{ix86}" from %go_arches,
I'm afraid :(

Fabio

[Miro Hrončok]

On 03. 07. 22 13:00, Fabio Valentini wrote:
> Go binaries that are used by non-Go packages.
>
> Those (and all their dependencies) would need to stay, unless those
> non-Go packages would also stop building on i686.
> This includes both build-time and run-time dependencies.
> Or, if the package in question is noarch, you'd need to make sure that
> it's not ever built on a i686 build host, and doesn't use the
> functionality provided by the Go binary at runtime.

An example:

act (Go) -> lib3mf (C/C++) -> openscad (C++)

Here, you cannot simply drop i686 from act, you would need to ExcludeArch: 
%{ix86} from openscad (I've already done that), lib3mf (on my TODO), act. In 
this order.

So simply dropping i686 from %golang_arches is not a thing that has no impact.