Hi Daniel, Thanks for the very long explanation (I especially appreciated the ascii-art diagram) but I don't quite agree. While I don't see any harm in -db not depending on libosinfo, I really don't see the benefit of going as far as to providing a separate package for db tools. The -db does not necessarily be only data either. I'd just keep the tools in -db or libosinfo and avoid the maintenance and packaging headache. On Fri, May 13, 2016 at 5:01 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Fri, May 13, 2016 at 04:24:52PM +0100, Zeeshan Ali (Khattak) wrote: >> Hi Daniel, >> >> On Fri, May 13, 2016 at 12:56 PM, Daniel P. Berrange >> <berrange@xxxxxxxxxx> wrote: >> > As mentioned previously we need to split off the database >> > from the main libosinfo library. In order todo so, we need >> > some tools to manage the database. One of those is the >> > pre-existing osinfo-db-validate command, but in future >> > it will be joined by osinfo-db-import & osinfo-db-export >> > to let admins import/export tar.gz or zip (TBD) archives >> > of the database independantly of the libosinfo library >> > releases. >> > >> > The new repository is at: >> > >> > https://gitlab.com/libosinfo/osinfo-db-tools >> >> I understand and agree that we need a separate repo/package for db but >> why a separate repo for tools? Why can't this be part of -db itself or >> kept as part of libosinfo even? > > The actual 'osinfo-db' package should be 100% data - we don't want to > have any shipped code in it at all. Beyond that the general point is > to decouple the concept of libosinfo the API, from osinfo the database, > to better serve projects which do not wish to use libosinfo the API. > > As part of this decoupling there's a clear need for some tools to > manage the deployment and distribution of the database, irrespective > of whether you are installing / using the libosinfo API. So the intent > is that 'osinfo-db-tools' provides the home for those tools that are > just focusing on managing the database deployment/distribution, and > are something everyone can depend on using. > > Now, we could have the DB tools as part of libosinfo GIT and just > package them in a separate RPM, but that introduces a mutual > dependancy between osinfo-db & libosinfo. You need to tools to > deploy the osinfo-db content, but libosinfo in turn wants the DB. > > Further there's no real compelling benefit to having them in the > same repository - the anticipated osinfo-db-* tools won't share > any code with the rest of the osinfo programs, since they are not > based around use of the libosinfo API - they merely use glib and > other related 3rd party libraries. > > So thing of this as providing distinct layers of the stack > > > +-----------+ +------------+ +-------+ +--------------+ > | openstack | | libguestfs | | Boxes | | virt-manager | > +-----------+ +------------+ +-------+ +--------------+ > | | | | > v v v v > +-----------------+ +-----------+ > | osinfo-db |<--------| libosinfo | > +-----------------+ +-----------+ > | > v > +-----------------+ > | osinfo-db-tools | > +-----------------+ > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- Regards, Zeeshan Ali (Khattak) _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
