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

[Daniel P. Berrangé]

On Fri, Feb 09, 2018 at 06:01:53PM +0000, 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.
> 
> My suggested split would be something like this:
> 
> * libguestfs: The library, daemon and appliance.  That would include
>   the following directories in a single project:
>        appliance
>        bash
>        contrib
>        daemon
>        docs
>        examples
>        gnulib
>        lib
>        logo
>        test-tool
>        tmp
>        utils
>        website
> 
> * 1 project for each language binding:
>        csharp
>        erlang
>        gobject
>        golang
>        haskell
>        java
>        lua
>        ocaml
>        php
>        perl
>        python
>        ruby

So, the core library above would still include the API description
and "make install" it into some location, such that these language
bindings cna auto-generate themselves I presume. I guess that means
you would rarely need to do releases of these language bindings, as
one release ought to be capable of being built against multiple
versions of the core library ?

> * virt-customize and related tools, we'd probably call this subproject
>   "virt-builder".  It would include virt-builder, virt-customize and
>   virt-sysprep, since they share a lot of common code.

Makes sense to have virt-builder as a thing in its own right.

> 
> * 1 project for each of the following items:
> 
>        small tools written in C
>           (virt-cat, virt-filesystems, virt-log, virt-ls, virt-tail,
> 	   virt-diff, virt-edit, virt-format, guestmount, virt-inspector,
> 	   virt-make-fs, virt-rescue)
> 
>        guestfish
> 
>        virt-alignment-scan and virt-df
> 
>        virt-dib	   
> 
>        virt-get-kernel
> 
>        virt-resize
> 
>        virt-sparsify
> 
>        virt-v2v and virt-p2v
> 
>        virt-win-reg

Ok

> 
> * I'd be inclined to drop the legacy Perl tools virt-tar,
>   virt-list-filesystems, virt-list-partitions unless someone
>   especially wished to step forward to maintain them.
> 
> * 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.

I guess sub-modules are reasonable for this, unless you actually
modulized the generator itself, such that the language binding
generation code could be a loadable module. That way the core
generator could be in the core library (and its -devel) package,
and the language binding repo could have the langauge specific
plugin for the generator ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|