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
