[Libguestfs] Continuing the split (was: Let's split up the libguestfs git repo and tarballs)

[Daniel P. Berrangé]

On Fri, Nov 29, 2019 at 12:09:47PM +0000, Richard W.M. Jones wrote:
> So, the difficulty of git submodules aside, we have now split off
> virt-v2v and virt-p2v into separate projects.
> 
> I also yesterday split off the boot analysis tools into a repo which
> is likely to be rarely used and which I'll probably not bother to
> package in Fedora.
> https://github.com/libguestfs/libguestfs-analysis-tools
> 
> Where do we go from here?
> 
> I think one of three ways.  Either:
> 
> * (1) * All libguestfs tools, whether written in C or OCaml, are
> sufficiently similar to each other and so are moved into a new
> libguestfs-tools project.

>From your original mail I see this

       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

Most of these are fairly low level core tools just exposing some
libguestfs APIs / functionality in a slightly more convenient way
than guestfish, whether in C or OCaml.

v2v & p2v are full applications in their own right & have split
already which makes alot of sense.

The other one here that feels like an application, as opposed to
a convience wrapper, is virt-dib. So I think perhaps that one
could be a separate repo. Everything else feels fine to be bundled
as one to me.

> libguestfs.git would end up containing only the daemon, core library
> and language bindings.  (Splitting out the language bindings is
> technically difficult because of their interdependence with the
> generator, and the language bindings are closely related to the API,
> so I don't see the point of splitting them out anyway.)

What about "guestfish" ?  Do you consider that "core" or an
add-on tool ? To me it feels like a core thing you'd expect
to always get when you have libguestfs, so perhaps that should
be in the main repo rather than tools repo.

> Or:
> 
> * (2) * Libguestfs tools in OCaml are different, and heavier-weight,
> from the C ones so we put those in a new project (named ...?)  The
> libguestfs tools in C are "lightweight" in some sense so we keep those
> in libguestfs.git.

Users shouldn't know or care what language the tool uses,
so exposing an arbitrary split of tools into 2 groups based
on language feels undesirable. Doubly undesirable if there's
a chance some of those C tools will get ported to OCaml.


> * (3) * Libguestfs tools in C and OCaml are different from both
> libguestfs and each other, and so we should move them into two new
> projects (again, naming suggestions welcome).

Same thoughts as option (2).

> I'm not especially wedded to a particular approach, but I would like
> to get something going on this sooner rather than later.

To me it looks like something close to (1) is most sensible.


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 :|