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 _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
