Re: [Libguestfs] 1.39 proposal: Let's split up the libguestfs git repo and tarballs
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