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

[Richard W.M. Jones]

On Fri, Nov 29, 2019 at 12:24:06PM +0000, Daniel P. Berrangé wrote:
> On Fri, Nov 29, 2019 at 12:09:47PM +0000, Richard W.M. Jones wrote:
> > * (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

Some of the difficulty here is about what can be easily split from
other things.  The generator in particular (since it's in
libguestfs.git) ties various things into the core repository:

  https://github.com/libguestfs/libguestfs/blob/355bed63f46a0e5c15aa9cbaa7ee3551969bc34d/generator/main.ml#L76-L367

In fact I've now noticed/remembered that guestfish contains a
significant amount of generated code, which makes sense since it is
essentially the language binding for shell script. This argues for
guestfish staying in the libguestfs repo.

>        virt-alignment-scan and virt-df
> 
>        virt-dib	   
> 
>        virt-get-kernel
> 
>        virt-resize
> 
>        virt-sparsify
> 
>        [virt-v2v and virt-p2v - already split out]
> 
>        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.

virt-dib is almost independent from everything else, so it might be
split into its own repo.  OTOH splitting it first into a tools repo
doesn't preclude further splitting later.  This is really one for Pino
to decide on.

virt-builder is also definitely an application.  However as it depends
on virt-customize it could only really be moved together with
virt-customize (and virt-sysprep for the same reason).  Again,
splitting these initially into a tools project doesn't prevent further
splitting in future.

virt-win-reg is written in Perl so it's the odd one out ...

There are also some legacy tools written in Perl
(virt-list-filesystems, virt-list-partitions, virt-tar).  They haven't
been packaged in Fedora for many years (not since April 2015 in fact)
so I may drop them.

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

Yes I think it's core - see above.

> > 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).

Agreed.

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

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW