On Sat, Feb 15, 2014 at 02:56:13PM +0000, Colin Watson wrote:
> On Fri, Feb 14, 2014 at 02:19:10PM +0000, Robie Basak wrote:
> > On Fri, Feb 14, 2014 at 09:03:17AM -0500, Scott Moser wrote:
> > > Fair. However, the 40M of space *is* permanent waste.
> >
> > In addition, we're promoting doing things in containers more and more -
> > particularly in server deployments. The 40M gets multiplied by the
> > number of containers you have on a system. And currently, we end up
> > fetching this for each container, too.
>
> These are separate problems; there's no intrinsic reason why the
> defaults for a container should have to be the same as the defaults on a
> bare-metal installation. In fact, given how LXC templates work, if they
> are the same it's because somebody made an explicit choice to that
> effect.
It's indeed an explicit choice. Since 12.04, we've tried very hard to
keep our templates as close to a standard install as possible.
Someone should be able to copy an existing Ubuntu system into a
container or copy a container rootfs onto a real machine and both should
work exactly as expected (well, except for you needing to install a
kernel and bootloader in the second case, obviously).
We expect anyone following software installation instructions to be able
to use those identically on a standard install or in a container.
Dropping i386 by default in containers would break that.
Note also that a lot of users are using containers specifically to
contain proprietary software they don't trust and those are very often
i386 multi-arch packages, so the i386 on amd64 use case in container is
a fairly common one.
(If our main concern here is JuJu and the way it deploy services, it may
be worth having JuJu just customize its image using cloud-init userdata
or similar to turn off i386 if it won't need it, but I'd be opposed to
doing this by default unless it's a project wide change.)
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
