* Justin Forbes: > On Tue, Aug 31, 2021 at 12:14 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: >> >> * Matthew Miller: >> >> > This is an off-shoot thought of the 32-bit ARM conversation. Right now, we >> > build stuff like libreoffice for i686, but then (mostly) don't ship it. >> > This seems like a waste of resources and time. >> > >> > I know it's somewhat complicated (for example, there's actually a library >> > package in libreoffice, libreofficekit, so that gets plucked in to >> > multilib), and there's quite a lot to work out, but ... does this seem like >> > a good intended direction? >> > >> > One immediate way to do this is to start adding `ExcludeArch: i686` to >> > "leaf" packages (I mean: to allow / encourage people to do that). But I >> > don't want to add _more_ cruft to the standard minimal spec file, so this >> > seems like the wrong direction. And I still think we want to keep multilib >> > for compatibility (hello, old games!). Could we do something clever in koji >> > instead? >> >> Is really a good use of our time to maintain these exclusion lists? >> >> We could selectively disable LTO on i686 (on other more challenging >> stuff, if there is any). But thinking about whether something should be >> built on i686 seems like a distraction. >> > > While it might take a good bit of time to sit down and figure out > exactly what is *useful* from a multilib standpoint, I don't think > that is necessary at this time. It really could be simplified to "do I > build a library or not?". if the package ships a library, keep > building it for i686, if not, you can disable it. It isn't an optimal > solution, but it would probably cut down considerably on build time, > and resource usage. Our buildroots are not multilib. We absolutely need m4.i686 even though it does not provide any libraries. Turning buildroots into multilib configurations would perhaps be nice (because it would allow us to get rid of glibc32 trivially), but it's also not something that delivers returns into the indefinite future. There seem to be Koji/mock development tasks which much higher rewards. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
