Splitting off the database (and tools)

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

 



I've talked about splitting off the database several times in the past,
and I think we're now in a position to do exactly that.

The two core goals of splitting off the database are

 - Make it easy to issue updates to the DB without updating the code.
   This will help LTS distros which are often loathe to upgrade the
   code, but still wish to pull in DB refreshes frequently

 - Enable apps to consume the database without going via the libosinfo
   library API. libguestfs already does this, and openstack wants todo
   this, so they can avoid a dep on c libraries for python access

Anyway, my thoughts on the approach to doing this are as follows..

 - We want some way to deploy a downloaded database into the right
   place. a "osinfo-db-import" tool.

 - We want some way to take a directory containing a database and
   bundle it into distributable format, merging translations as
   it goes. a "osinfo-db-export" tool

Both of these would basically be thin wrappers around tar or zip I
think.

We already have an "osinfo-db-validate" tool that is used to validate
the database against the published schema.

So, I'm thinking we should create a 'osinfo-db-tools' package / GIT
repo which contains the RNG schema, and the aforementioned tools.
This would be the minimal set of C tools that something like OpenStack
would want to use & depend of.  I would create thisi GIT repo by taking
the current GIT repo & just trimming the bits that are not applicable.
That way we keep GIT history intact for the existing RNG schema and
osinfo-db-validate tool.

For the actual database we would have a 'osinfo-db' package & GIT
repo. This would *not* contain any automake/autoconf stuff. It would
contain the actual XML files for the DB, test data (all the .iso header
text files) and .po files with translations for the XML. To publish the
contents of this GIT repo, we'd simply use the osinfo-db-export tool to
create a distributable archive of it. Again, I'd start with current GIT
and just trim out bits to leave what we want, to preserve GIT history

The current libosinfo GIT repository would have its data/ directory,
the tools/osinfo-db-validate and tests/isodata/ files deleted. Its
RPM would gain a Requires: on osinfo-db-tools and osinfo-db, so that
from end user point the upgrade path is seemless.

For the osinfo-db package I don't think we'd bother doing formal
releases manually. Instead I think I'd just setup a cron job that
runs osinfo-db-export and publishes the result on libosinfo.org
once a day. So we'll always have latest data published for consumption.

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 :|

_______________________________________________
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