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.