Re: [osinfo-db-tools 0/2] Start new osinfo-db-tools package

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux