On Fri, May 13, 2016 at 11:13:02PM +0100, Zeeshan Ali (Khattak) wrote: > On Fri, May 13, 2016 at 5:56 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > > On Fri, May 13, 2016 at 05:35:15PM +0100, Zeeshan Ali (Khattak) wrote: > >> 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. > > > > Actually I think it would make maintenance easier because it avoids > > tieing together things that would naturally evolve seprately. For > > example, there could be cases where a distro would want to update > > the DB management tools, but not pull in a new library version, > > or vica-verca. Letting these things evolve separately with their > > own release schedules will make life simpler for people consuming > > them, as they won't be faced with mutually exclusive decisions about > > which updates to pull in if they want to rebase some parts but not > > others. > > > > This may not sound like a big deal when all osinfo-db-tools contains > > is a couple of command line tools for validate & unpacking archives, > > but I've mentioned ideas before about providing tools to periodically > > query & download updated database version, so the osinfo-db-tools > > package is likely to gain more functionality & complexity over time. > > So I think over the long term the split will be beneficial to all > > involved. > > But why are we being religious about "no code in -db" package? It makes life much easier to get updates into distros. For example, if the package is 100% pure data, then for RHEL we can likely get an exception to allow updating of the data for every single release, as is done with updating things like pci.ids & usb.ids package. If the rebase included any amount of code / tools too, then there is increased risk and would need to go through the normal update approval workflow. 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
