canonical-ci-engineering team mailing list archive

[Sergio Schvezov <sergio.schvezov@xxxxxxxxxxxxx>]

On Wed, May 13, 2015 at 06:09:01PM +1200, Thomi Richards wrote:
> Hi Sergio,
> 
> 
> I tried to get hold of you on IRC today, but I guess I must have missed you.

It's because I am off this week ;-)

> The CI team need a way to generate a snappy image with one or more
> additional debian packages applied.
> 
> Our current approach is to regenerate the rootfs tarball for the latest
> image, mount it in a chroot, install the new packages, unmount it, and then
> (hopefully) pass that modified rootfs tarball to u-d-f and have it generate
> an image based on our modified tarball, rather than the one downloaded from
> the image server.
> 
> I've had a look at the source code today for u-d-f (BTW, trunk FTBFS, as
> lp:snappy/progress API seems to have made backwards-incompatible changes),
> and this doesn't seem like it would be very difficult, but there's enough
> alien code in there that I'm not confident enough to do it myself.

Will fix when I get back (the new incarnation of u-d-f is moving into
snappy itself fwiw).

> Do you think this is a plausible / sane approach?

It would of been before the plan to move the rootfs to a snappy package.

Even though we use debs to build the image today, we might not in the
future.

Do you need debs btw? Isn't it possible to solve your problems by creating
a snappy framework package?

> Is this something you'd be willing to add to the u-d-f tool?

Not anymore, support for system image is going away. It can be added,
but would be short lived, so I guess it depends on the immediate gains
this option will provide.

> Any comments / thoughts on our approach?

When the OS is delivered as a snapppy package we can add an interface to
replace it.