On Mon, Mar 07, 2022 at 03:01:32PM -0500, Simo Sorce wrote:
On Mon, 2022-03-07 at 20:32 +0100, Fabio Valentini wrote:
> On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
> >
> > So, I'll go ahead and be a bad guy here:
> >
> > Perhaps it's time to just retire i686 completely?
> >
> > Steam is available as a flatpak, and old software thats 32bit only and
> > can't be rebuilt could just be run from a f36 container?
> >
> > This would save us:
> >
> > * all the builder resources
> > * all the multilib calculation time/space in composes
> >
> > If we don't want to retire it now, when will we?
>
> I have considered this option, but I don't think we can do that yet.
>
> For example, as far as I know, you need the 32-bit host libraries for
> running 32-bit Windows applications in Wine.
> Dropping that would make our Wine packages almost useless, since a
> large fraction of Windows software still isn't 64-bit.
>
> But I could be wrong. And if we indeed don't need wine.i686 to run
> 32-bit Windows apps, retiring i686 entirely would be an option, I
> agree.
> (I myself am using the Steam flatpak you mentioned. It works well, and
> I don't need 32-bit libs on my host system at all, which is nice.)
Wouldn't wine problem be solved by providing the 32bit version as a
flatpak if still needed for some corner cases?
I'd really prefer that we don't go down this static-linked blob route.
There's a reason I'm using a proper distro.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org