<div dir="auto"><div>Hi,</div><div dir="auto"><br></div><div dir="auto">We're certainly not opposed to moving the image bits to a separate package. Especially, if you'd write the patch. At least I don't see any reason not to do it. I'll forward this to Stéphane as well. If you want you can open this as a separate topic on <a href="http://discuss.linuxcontainers.org">discuss.linuxcontainers.org</a>. It will have more visibility over there. :)</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Christian</div><div dir="auto"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Jul 16, 2017 14:47, "Nelo-Thara Wallus" <<a href="mailto:nelo@wallus.de">nelo@wallus.de</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Morning list,<br>
<br>
Docker recently added multi-stage[1] builds, which allow to e.g. build<br>
an application in one layer, then only copying the resulting build to<br>
a new, slimmer, layer, removing the whole build toolchain.<br>
<br>
[1]: <a href="https://docs.docker.com/engine/userguide/eng-image/multistage-build/" rel="noreferrer" target="_blank">https://docs.docker.com/<wbr>engine/userguide/eng-image/<wbr>multistage-build/</a><br>
<br>
I've wanted something like that for LXD as well, however I only found<br>
maryvilledev/lxb[2], which requires the host to run LXD instead of only<br>
building the tar ball to spec.<br>
<br>
[2]: <a href="https://github.com/maryvilledev/lxb" rel="noreferrer" target="_blank">https://github.com/<wbr>maryvilledev/lxb</a><br>
<br>
Currently I'm working on a prototype at ntnn/lxb[3], however I'd like to<br>
use the structs and functions which already exist in the LXD codebase,<br>
instead of reverse-engineering each step.<br>
<br>
[3]: <a href="https://github.com/ntnn/lxb" rel="noreferrer" target="_blank">https://github.com/ntnn/lxb</a><br>
<br>
Would you be open to a patch which moves the image spec/metadata<br>
parsing/etc.pp. into its own package, so it can be used as a library by<br>
third party tools?<br>
<br>
I'd leave all the actual handling, e.g. importing, exporting, ... in<br>
the lxd package, but functions like detectCompression, unpack{,Image},<br>
compressFile, etc.pp. would be quite handy to not differ between an<br>
image builder and the actual daemon handling the images.<br>
<br>
Cheers,<br>
Nelo<br>
<br>
--<br>
/"\  ASCII Ribbon Campaign<br>
\ /  - against HTML emails<br>
 X   - against proprietory attachments<br>
/ \  <a href="http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign" rel="noreferrer" target="_blank">http://en.wikipedia.org/wiki/<wbr>ASCII_Ribbon_Campaign</a><br>
<br>
<br>______________________________<wbr>_________________<br>
lxc-devel mailing list<br>
<a href="mailto:lxc-devel@lists.linuxcontainers.org">lxc-devel@lists.<wbr>linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-devel" rel="noreferrer" target="_blank">http://lists.linuxcontainers.<wbr>org/listinfo/lxc-devel</a><br>
<br></blockquote></div><br></div></div></div>