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 <firstname.lastname@example.org> 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
> > email@example.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel