Re: [Libguestfs] Splitting the large libguestfs repo
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...
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.
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
--
Pino Toscano
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)