Re: [Libguestfs] Splitting the large libguestfs repo
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