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 <li...@cmadams.net> wrote: >> >> Once upon a time, Fabio Valentini <decatho...@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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
