[Libosinfo] osinfo-db source tarball

[Guido Günther]

On Fri, Oct 21, 2016 at 10:50:44AM +0100, Daniel P. Berrange wrote:
[..snip..]
> > So I took a different approch and ran:
> > 
> >     git archive HEAD | xz -c > ../osinfo-db_0.20160728+git20161020.orig.tar.xz
> > 
> > and used that as the source tarball for building.
> 
> IMHO that does really help in any way. The only difference between

s/does/does not/?

> xml and xml.in files is the translation data. So having the xml.in
> and .po files in deb packages is not doing anything useful. Translations
> updates have to go via the Zanata translation system, and any content
> updates are fine to send in the .xml files

The .in files are only ever in a source package, they never end up on a
users system. They're used merely used for building the package. The
merging of the .in files creates more fuzz than just adding
translations like trailing spaces when dropping comments.

Using the generated XML makes carrying distro specific patches harder
than necessary (not that intend to not forward upstream but you never
know). Furthermore generating from the .in files makes sure we're able
to build the xml from within Debian (i.e. have all the tools packaged).

> 
> > > > * contains the Makefile to execute and run the build so we can use the
> > > >   preferred form of modificaation?
> > > 
> > > You are *not* supposed to unpack the tarball manually. Run the
> > > osinfo-db-import tool, passing it the tarball, as described at
> > > 
> > >    https://libosinfo.org/download/
> > 
> > Yes, I'm doing so after rebuilding the XML files:
> > 
> >     https://anonscm.debian.org/cgit/pkg-libvirt/osinfo-db.git/tree/debian/rules#n10
> > 
> > So would it make sense to build two things: the tarball as shipped atm
> > plus a separate one (osinfo-db-source_<date>.tar.xz) as generated above?
> > If so I'd send a patch for the Makefile to generate both.
> 
> No, I don't think providing a raw tarball is useful at all and certainly
> don't want to encourage anyone else to do that.

Fine with me. I can stick to the above method for generating a source
tarball (from the released tags in the future).

> The long term intention is to actually provide more tools to automate
> the process of downloading & deploying newer osinfo-db archives,
> independantly of what the OS vendor provides, because the OS vendor
> provided data is inherantly always out of date, particularly for long
> term distros like Debian / RHEL.

Now with the db split out I'm looking forward to update the database
files on point releases. Thanks for making this possible with the split!

Cheers,
 -- Guido