Currently the 19.10 daily amd64 image ships with no foreign architectures. This makes installing 32-bit software such as Steam (and others) difficult for new users. The 19.04 amd64 release images had i386 foreign architecture enabled by default, so this seems to be a regression since the last release.
I appreciate there have been many longdiscussions about the (possible) future(s) of i386 packages and support. However, as I understand it, right now 19.10 ships with i386 packages in the archive, and will do on release day. So for an amd64 install, I would expect there to be an i386 foreign architecture configured.
Steps to reproduceâŠ
Boot 19.10
Run dpkg --print-foreign-architectures in a terminal
Iâd expect i386 in the output, but get nothing.
I appreciate the workaround is to use dpkg --add-architecture i386 but thatâs impenetrable tech nonsense for normals who just want to install the latest Ubuntu, get Steam and start gaming. It will also exacerbate the (still held) opinion among our users and detractors that we are âkilling gaming on Linuxâ by making i386 software installations difficult.
Our most recent statement on the matter says It has always been our intention to maintain usersâ ability to run 32-bit applications on 64-bit Ubuntu â our kernels specifically support that.
This was the result of a change made at the time we intended to drop the i386 architecture. The apt-setup change was reverted soon after it became clear we would not drop i386 from the archive, but the change did not get propagated to ubiquity because it had not been reuploaded.
Anyone installing eoan with beta or later media will get the prior expected behavior, of i386 enabled by default.
Is this on a fresh install or an upgrade? If it is an upgrade from which media did you install? You can check via âcat /var/log/installer/media-infoâ.
Ok, I stand corrected. On the live CD, itâs showing the incorrect behavior, but the installed system (with updates) shows the correct behavior. On Lubuntu, itâs incorrect on both, though. So whatâs Lubuntu missing?
I donât know enough about how these components interact to know why it works fine on Ubuntu but not Lubuntu? Is it anything to do with the fact that Ubuntu uses Ubiquity and Lubuntu uses Calamares, perhaps?
The âfixâ was just undoing an change made previously which removed i386 support from amd64 installs.
Was the feature ever in Calamares based installs to enable the i386 foreign arch on non-ubiquity based installs? Perhaps thatâs just been a missing feature of that installer? Because to me it looks like itâs âalwaysâ (i.e. for a long time) been on the Ubiquity installs, just an oversight when Calamares was introduced, relatively recently.
Sounds like a bug needs to be filed against Calamares and tracked there?
Calamares is a general installer meant to work over a wide variety of package managers. Thatâs a good thing because itâs applicable to a wide variety of distros. However, that makes it a little less specific, too. I guess itâs reasonable that they could allow some configuration option to select architectures, but you got to admit, this is a pretty weird edge case given the vast majority of install situations across many distros.
That said, instead of hiding the idea in Ubiquity, if we had it in casper instead, it would have two benefits:
Regardless of installer used, everyone would get the right architectures. I imagine this could benefit derivatives and remixes as well as official flavors.
All of the right architectures would be there in the live system, which would have the added benefit of supporting folks that are using live with persistence.
If we want the change to apply everywhere, it seems to me we should build images with the foreign architecture enabled rather than enabling in both casper and the installer separately. I donât know if thereâs a reason that would be a bad idea though.
