I don't think we're ready to take advantage of shared libraries - they are still highly experimental and evolving, and I'd rather not be the tip of the spear on that.
On Wed, Nov 1, 2017 at 11:44 AM, Daniel Walsh <dwa...@redhat.com> wrote: > On 11/01/2017 11:25 AM, Dusty Mabe wrote: > >> >> On 11/01/2017 11:17 AM, Daniel Walsh wrote: >> >>> Basically we are looking to move kpod out of the >>> kubernetes-incubator/cri-o project to allow it to grow on its own. We >>> plan on building out the library for creating container pods to such an >>> extent that CRI-O could use it as well as kpod. >>> >>> Since kpod is outgrowing the original goals of the CRI-O project we >>> thought it best to move it to its own repository. >>> >>> We plan on continuing to have kpod, buildah, cri-o and skopeo all able >>> to share the same containers/storage and containers/image libraries. >>> >> Unfortunately installing them all on a system will mean you get statically >> compiled duplicate copies of containers/storage and containers/image. I >> think >> in recent go versions "shared library" support has been getting better. >> Could >> we start to do some of this for our go tools that use common libraries? >> > Well this is no worse then what we have now, since kpod and crio were not > sharing the same code base. > As shared libraries become better we will definitely take advantage. > > >> Note: There is a good change the kpod will change it's name, but for now >>> we will keep it as kpod, and the repo will be based on the library name >>> to prevent confusion. >>> >>> >>> Dan >>> >>> >
