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

[Daniel P. Berrange]

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 at redhat.com> 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 :|