Re: osinfo-db source tarball

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 20, 2016 at 07:55:10PM +0200, Guido Günther wrote:
> Hi Daniel,
> On Tue, Oct 18, 2016 at 09:30:49AM +0100, Daniel P. Berrange wrote:
> > On Tue, Oct 11, 2016 at 08:32:05PM +0200, Guido Günther wrote:
> > > Hi,
> > > I looked into packaging osinfo-db for Debian and looking at:
> > > 
> > >   https://fedorahosted.org/releases/l/i/libosinfo/osinfo-db-20160728.tar.xz
> > > 
> > > it looks quit different from https://gitlab.com/libosinfo/osinfo-db
> > > . Would it be possible to ship a proper source tarball that:
> > > 
> > > * contains a license file
> > 
> > The tarball isn't supposed to contain anything other than the DB XML
> > files. Indeed the way it is created is by running osinfo-db-export
> > on the installed database directory, so it won't pick up anything
> > other than the files in that dir, so no license file will be found
> > there.
> 
> I think it's not exacthel the "source" tarball then. It's the "binary"
> tarball that contains the database files. I like to be sure we can
> rebuild the xml files from the xml.in files.
> 
> In Debian people often fetch the source package, apply pathes on top of
> it and post these to the bug tracking system (because we have lots of
> tooling around it). I'd like to make this as simple as possible
> (including forwarding this upstream you libosinfo authors).
> 
> 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
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

> > > * 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.

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux