The packaging effort is real; it’s just unevenly distributed across different types of
packages, so some packagers might not have noticed it.
Packaging work that, with the demise of 32-bit ARM, can now be ascribed purely to these
generally-unused i686 packages includes:
- As Fabio noted, occasionally disabling LTO or reducing debuginfo to keep compilers
operating within 32-bit resource limitations.
- Debugging test failures related to 32-bit platforms—on which upstreams typically don’t
or can’t test, so these are more and more common.
- Developing, testing, and submitting patches for 32-bit bugs.
- Creating, and seeing in the packager dashboard, mandatory ExcludeArch bugs that
basically say “upstream doesn’t care about 32-bit architectures and never will, and the
problems are too fundamental to fix downstream.” These are noise, since they will never be
fixed.
- Creating even more ExcludeArch bugs for the dependent packages of libraries that don’t
support 32-bit platforms.
- Making noarch Python packages arched because a dependency of an “extra” is 64-bit-only,
so we need to conditionally produce the corresponding extras metapackage
everywhere-but-i686.
- Conditionalizing weak or optional dependencies that don’t support 32-bit—again, forcing
some noarch packages to become arched.
Some categories of packages seem to very rarely need this kind of work. In others, like
scientific Python, 32-bit and big-endian issues are pervasive and can be the most
labor-intensive aspect of many packages. Finding a way to cut out the 32-bit part of that
really would make a difference.
On Wed, Mar 9, 2022, at 10:13 AM, Fabio Valentini wrote:
> On Wed, Mar 9, 2022 at 4:06 PM Chris Adams <linux(a)cmadams.net> wrote:
>>
>> Once upon a time, Fabio Valentini <decathorpe(a)gmail.com> said:
>> > Package maintainers who would benefit from dropping i686 from their
>> > packages probably already know that i686 is painful for them.
>>
>> So I guess this is the part I don't really understand (and I guess why I
>> don't see this proposal as a "win") - how is i686 painful to
package
>> maintainers for non-delivered packages? Maybe I'm just missing
>> something, but what causes issues?
>
> The problem is that those packages are painful to *build*.
> We don't ship most of them at all, but they're still *built*.
>
> And given limitations of 32-bit architectures (especially per-process
> and total memory) and ever-more-complex software, this is starting to
> hit more and more packages.
>
> For example, I already had to limit functionality or quality of
> debuginfo of some of my packages because otherwise they wouldn't
> compile in 32-bit environments *at all*.
> This is what's *painful* and makes no sense: Having to deal with
> architecture limitations, but for architectures where we don't even
> ship the resulting packages.
>
> Fabio
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
>
https://pagure.io/fedora-infrastructure