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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
