Files OS Snap provides

[Oliver Grawert]

Am Donnerstag, den 05.11.2015, 15:47 +0100 schrieb Mark Shuttleworth:
> On 05/11/15 15:24, Oliver Grawert wrote:
> > hi,
> > Am Donnerstag, den 05.11.2015, 09:10 -0500 schrieb Stéphane Graber:
> >
> >> Example manifest for wily:
> >> http://cloud-images.ubuntu.com/wily/20151104/wily-server-cloudimg-amd64.manifest
> >>
> >> Ignore the kernel and bootloader related packages from this manifest as
> >> they're not included in the root.tar.xz tarball which we're using
> > it is still rather gigantic compared to todays snappy rootfs (which is
> > supposed to shrink even futher (i.e. removing bash at some point), also
> > why are all the initrd handling bits in there i assume they could be
> > ripped out too or does anything in lxc use them ? (i'm currently doing
> > fine grained surgery to get them out of snappy rootfses where we do not
> > want them at all since you will never generate an initrd at runtime) 
> 
> All good questions to be asking in the run-up to 16.04 LTS :)
> 
> We want it:
> 
>  * as tight as can be (I like the Recommends clean-up)
>  * consistent across all the worlds we publish "headless Ubuntu"

but we already do not have any consistence across worlds here, thats the
problem with having different concepts. to support classic ubuntu server
there has to be the initramfs-tools package in the rootfs, you need
plymouth (and fonts etc) and cryptsetup preinstalled in the case you do
encrypt your rootfs etc etc.

on snappy you will not want any of this in your rootfs but instead have
an initrd that contains the bits an update-initramfs call on a deb based
server or desktop install would generate from this. your binary initrd
would be shipped by the device snap and only updated through this
mechanism, you dont need and want all these tools preinstalled in a
snappy rootfs due to the decoupling of HW and rootfs bits in snappy ... 

while lxc images might be a small base for deb based systems they do not
take the readonly rootfs, the removal of apt and dpkg from the image and
other bits into account. so even if we had the same package set,
accepting such package overhead in the readonly rootfs we would still
have to mangle it a lot (remove all dpkg and apt traces at least) to
make it suitable for snappy. snappy provides different behavior and
package handling so we cant really take a deb based rootfs 1:1 without
extra mangling.

looking at the lxc manifest above there is a lot of stuff we'd need to
adjust to be properly suitable for snappy which will end up in a lot of
hacks to the build system or in post-creation hacks to remove and mangle
stuff. i'm not sure it will be less maintenance work over maintaining
our own rootfs which is created the right way for snappy consumption
from the start.

having the same base for all deb based systems seems natural but at the
same time i think it doesn't fit so well into the snappy concept ...

ciao
	oli