New image organization and snap format

[Oliver Grawert]

hi,
Am Montag, den 11.01.2016, 10:36 -0300 schrieb Sergio Schvezov:

> I thought the list of snaps was going to come from the model
> assertion. Martin can you double check just in case? 

hmm, i have the feeling i need to elaborate about our image build
system a bit ...

there is the toplevel cdimage tool, that manages trigggering builds,
publishing them etc ... this tool calls livecd-rootfs which is a
wrapper around live-build. live-build then builds a) the generic rootfs
for a toplevel arch (armhf, x86, amd64) and then iterates over the
known supported subarches/kernels to generate the device specifc
tarballs (like device-foo-raspi2.tgz) based on the kernel package name
...
cdimage will publish this image to cdimage.ubuntu..com also based on
that naming scheme. 
we then consume that tarball in a snap to create a device/kernel snap
...

either cdimage needs to know about the mapping to name the resulting
tarball (which will serve as input for the snap) in a way the
subsequent steps in the build system know about it, or we do not build
these snaps automated and the person that manually rolls the snap knows
about the mapping (this is what happens today for our handfull of
arches, the snap containing the bootloader simply gets rolled by hand).

today we simply use the name extension of the BSP kernel (or fall back
to -generic), so in case of the raspberry the image name gets the
"raspi2" extension because the kernel team picked this name, thanks to
this quasi-standard there is no need to have any mapping today ... if
we want automated builds for a snap that is differently named the build
system on a low level needs to know that mapping ... (which could
happen by pulling the gadget snap from the store, unpacking it and
obtaining the meta data, or it could come from a txt file we maintain
separately  containing a mapping table)

my point is simply that our system currently is designed for easy
scalability due to the naming practice (this stems from debian
-installer/ubiquity design) , if we want to use names like "blahblah-pc
-linux and foobar-pi2-linux" instead of the current schema, thats fine
but will make scalability harder or require some clever coding to
obtain the meta info...

i'm not talking about the high level of assertions and snaps but about
the lowest level of tarball (or soon squashfs) creation of the
artifacts consumed by the later snaps.

ciao
	oli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160111/228ceb7a/attachment.pgp>