[Libguestfs] Splitting the large libguestfs repo

[Richard W.M. Jones]

On Tue, Oct 15, 2019 at 03:59:04PM +0200, Pino Toscano wrote:
> On Tuesday, 15 October 2019 10:01:28 CEST Richard W.M. Jones wrote:
> > I got a little way into this.  The two attached patches are
> > preliminary work.
> 
> I see the work was done already, so I guess providing alternative ideas
> (or opinions, apparently) is of no use now...

It's always valued.

> > My proposed split is:
> > 
> >       libguestfs.git
> >           common -> git submodule libguestfs-common.git
> >           generator/
> >           lib/
> >           all language bindings
> >           C based tools (eg. virt-df, virt-edit, guestfish)
> >     
> >       guestfs-tools.git
> >           common -> git submodule libguestfs-common.git
> >           virt-builder, virt-customize, virt-sparsify, virt-sparsify, etc
> 
> I do not think splitting these tools in an own repository makes much
> sense.  What is the goal/advantage you get by splitting them in an own
> repository, compared to the ones left in libguestfs.git?  Users do not
> care about virt-customize written in OCaml rather than C, and it makes
> harder to eventually rewrite a C tool in OCaml.

This part of the split isn't absolutely necessary, I really wanted to
concentrate on virt-v2v and get that done, partly just because dealing
with virt-v2v inside the bigger repo is such a pain.

You're right that people don't care about what a tool is written in,
so another idea might be to put the C _and_ OCaml tools into the
guestfs-tools.git repo (leaving lib + daemon + language bindings only
in libguestfs.git).  In fact I like this better now I think about it.

> > The current common/ subdirectory would become a git submodule.  While
> > git submodules are awkward, they do solve this particular problem with
> > having common code shared across the repositories, there's only one
> > git submodule and it's under our control.  It does mean that any time
> > there's a change to common/, we would need to add a commit to the
> > other 3 repos updating the submodule hash.
> 
> The current common/ subdirectory is a giant mixup of different
> components needed by some or just one tool each; few examples:
> - common/mlaugeas -> only for the daemon
> - common/mllibvirt -> only for v2v
> - common/mlxml -> only for v2v
> - some of the ml modules are need by any OCaml stuff
> - some of the ml modules are used by 1/2 tools
> - etc

It's a step on the path rather than the end point.  We can definitely
move mllibvirt & mlxml to virt-v2v in future.  We can also try to
organize it better or split it in future.

The alternatives to the submodule are somehow packaging everything up
into a library, which would then become a build dep of the tools.
This isn't particularly nice because (as you say) it's a big mix of
miscellaneous "stuff", essentially a core library of missing C and
OCaml functionality that we happened to need.  So therefore not useful
as an independent library.

I'm not overjoyed by git submodules, but in this particular instance I
think it can make sense, and there's only one of them (at the moment,
we could change that).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v