[Libguestfs] 1.39 proposal: Let's split up the libguestfs git repo and tarballs

[Eric Blake]

On 02/09/2018 12:01 PM, Richard W.M. Jones wrote:
> My contention is that the libguestfs git repository is too large and
> unwieldy.  There are too many separate, unrelated projects and as a
> result of that the source has too many dependencies and takes too long
> to build and test.
> 
> The project divides (sort of) naturally into layers -- the library,
> the bindings, the various virt tools -- and could be split along those
> lines into separate projects which can then be released and evolve at
> their own pace.

Sounds reasonable to me as an observer.  Would you also create a 
meta-package that has all the other projects as submodules, and which 
gets a new commit any time any one of the submodules does a release, to 
still make it easy for someone who wants to grab everything that the old 
monolithic repo used to provide?

> * common code and generator: Off to the side we'd somehow need to
>    package up the common code and the generator for use by all of the
>    above projects.  It wouldn't be a separate project for downstream
>    packagers, but instead the code would be included (ie. duplicated)
>    in tarballs and upstream available as a side git repo that you'd
>    need to include when building (git submodule?).  This is somewhat
>    unspecified.

git submodules are a pain to work with sometimes, but they do sound like 
the best approach for what you are documenting here.  Dan Berrange's 
work on making keycodemapdb a submodule to multiple projects may prove 
to be a useful inspiration in the process.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org