On Thu, 13 Feb 2014, Scott Ritchie wrote: > Please don't, there have been a whole plethora of confused users not > understanding why certain packages aren't installable because they > installed with a method that didn't include i386 such as debootstrap. > > Also, I have run into a significant number of customers who use Wine > on Ubuntu Server. This would 100% break for them. > > It's only "Trivial to add" if you know exactly what to do here, and > understanding multiarch internals is not something even most syadmins > bother to do precisely because we've done such a good job at making > apt just work.
It is disabled in cloud-images for quite some time. (I think 12.10). I personally think its an extremely high cost bandwidth cost spread across Canonical, other mirror providers and the end user to account for a very rare case where someone would want to do this. That fresh install I just did, when I type 'apt-get update' (after rm -Rf /var/lib/dpkg/lists), apt tells me: with i386 enabled: Fetched 27.6 MB in 16s (1,655 kB/s) du /var/lib/apt/lists: 133M without i386 enabled: Fetched 20.2 MB in 11s (1,687 kB/s) du /var/lib/apt/lists: 94M So 40M of space and 7M of network traffic and 5 seconds of time (having hit a local proxy). I really think that 98% of all people who would possibly touch a amd64 server ISO will never install a i386 package. > > On Thu, Feb 13, 2014 at 1:26 PM, Adam Conrad <adcon...@ubuntu.com> wrote: > > On Thu, Feb 13, 2014 at 06:24:18AM -0500, Scott Moser wrote: > >> > >> I just did an ISO server install of trusty server, and I end up with > >> 'i386' in the output of: > >> $ dpkg --print-foreign-architectures > >> i386 > > > > It's been this way since (at least) precise on all amd64 installations. > > > >> I really wish we'd have done it earlier, but I really think that most of > >> the time this is just a waste of network traffic on 'apt-get update' on a > >> server. If people want i386 packages on amd64, its trivial for them to > >> re-enable it. > > > > So, if there's concensus that "server" installations shouldn't have a > > foreign arch enabled by default, we'd need to sort out how to fix this. > > > > Right now, it's done in the dpkg postinst, which has no clue whatsoever > > what's a server or a desktop. One could say "well, just enable it in > > ubiquity", but that cuts out all the desktop installations that are done > > via netboot/d-i methods. > > > > So, perhaps one could tear out the dpkg postinst snippet and put it in > > the postinst of an empty package called "i386-multiarch" and add that > > to the desktop-common seed, but the idea of having a package installed > > whose sole purpose is to execute a postinst on first install, and then > > lie inert for the rest of the life of your system also rubs me slightly > > the wrong way. > > > > Anyone have any better options (or arguments why server should get the > > same multiarch settings as desktops and, thus, the status quo is fine)? > > > > ... Adam > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel