I am kinda late to the party. This is indeed a much needed feature. Many distros have libosinfo package 6 mon+ old (missing recent OS releases). - Is XML the format we want to use long term ? I agree with switching to json if the performance gain is significant. Not a high priority if performance isn't going to be a concern in short term. If xml support does not get discontinued, some well defined precedence to handle conflicts (in case a copy of xml database and a copy of json database are present at the same time) seems necessary. - Do we need to mark a database schema version in some manner ? adding a hash associated with the version number to remind people if the database has been modified since released? adding a flag to prevent the database from getting overwritten by updates if the user wants to keep the modified version? - Should we restructure the database ? 1 entity per file instead of a huge file with everything makes sense. Easier to maintain. I agree with your approach in [PATCH 00/39] Split up database XML files https://www.redhat.com/archives/libosinfo/2015-September/msg00043.html - How do we provide notifications when updates are available Using DNS TXT record for update check is a brilliant idea. While having a separate package for database updates, I would like to see a method to update the database on demand outside the distro's package management (too much admin work and taking too long to publish). It can be as easy as a script to operate in diff/overwrite mode. The files can be hosted on github or with cloudflare cdn so libosinfo.org won't get hammered too much. I tried to replace everything in /usr/share/libosinfo/db with the /data (except /data/schemas) from git and /usr/share/libosinfo/schemas with data/schemas. It did not work. Is there any change that prevents the current database from working on 0.2.11? libosinfo.x86_64 0.2.11-4.el7 @anaconda/7.1 $ osinfo-query os Short ID | Name | Version | ID ----------------------+----------------------------------------------------+----------+----------------------------------------- Yang _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
