[virt-tools-list] virt-viewer dependency on newer spice-gtk

Jonathon Jongsma jjongsma at redhat.com
Tue Oct 13 15:23:22 UTC 2015


On Mon, 2015-10-12 at 17:51 +0100, Daniel P. Berrange wrote:
> On Mon, Oct 12, 2015 at 11:46:05AM -0500, Jonathon Jongsma wrote:
> > On Mon, 2015-10-12 at 14:54 +0100, Daniel P. Berrange wrote:
> > > On Mon, Oct 12, 2015 at 08:50:12AM -0500, Jonathon Jongsma wrote:
> > > > On Mon, 2015-10-12 at 10:26 +0100, Daniel P. Berrange wrote:
> > > > > On Fri, Oct 09, 2015 at 04:15:13PM -0500, Jonathon Jongsma wrote:
> > > > > > Unfortunately, there was no single-header include for the GTK+ library
> > > > > > until just recently (spice-client-gtk.h), so this requires bumping the
> > > > > > spice-gtk version requirement to a unreleased git version.
> > > > > 
> > > > > IIUC this is going to prevent virt-viewer being built against existing
> > > > > released of spice. I think this is a rather unpleasant API break for
> > > > > SPICE to force on client programs.
> > > > > 
> > > > > I would really expect there to be several releases where SPICE provided
> > > > > the new single-header that apps could use, while *also* allowing apps
> > > > > to continue to include the more specific headers. ie, give apps some
> > > > > grace time to switch over to the new style. Can you try and re-visit
> > > > > this in SPICE first.
> > > > 
> > > > Actually, the only changes I have pushed to spice are those that:
> > > > 
> > > > - add this new spice-client-gtk.h master header
> > > > - produce a compiler #warning when including one of the sub-headers
> > > > 
> > > > So, at the moment, it is still possible to build virt-viewer against
> > > > both released and unreleased (git master) spice-gtk. In the latter case,
> > > > we'll just get compile warnings. This patch adds a dependency on git
> > > > master to try to avoid those warnings. But we can delay this patch and
> > > > simply live with the warnings for a little while if that's what people
> > > > prefer.
> > > 
> > > My general desire is that virt-viewer *always* be capable of building
> > > against the most recent Fedora stable branch, because when I build
> > > release binaries (eg for Win32) I don't want to be using unreleased
> > > code or Fedora rawhide. I want to use a known good stable Fedora release
> > > Mingw toolchain.
> > 
> > This dependency obviously only applies to virt-viewer in git master. Are
> > you suggesting that virt-viewer from git should always be buildable
> > against the version of spice-gtk in fedora? Or are you talking about
> > virt-viewer releases? As I said, I can probably delay this patch for a
> > while if that's what people prefer, but at the moment I'm not sure I
> > totally understand what you're requesting.
> 
> What is currently in virt-viewer GIT master will become the next
> release of virt-viewer. We don't want the next virt-viewer release
> to be blocked on a Fedora release. Thus virt-viewer GIT master must
> always build on most recent Fedora release.

Hmm, to me that seems overly restrictive for virt-viewer development. I
have not followed this policy for the current development cycle and
nobody has complained so far. Until quite recently virt-viewer did
depend on spice-gtk from git. But Christophe packaged and built the new
spice-gtk 0.30 very soon after it was released, and I believe it is now
already available for fedora 22-24.

Jonathon




More information about the virt-tools-list mailing list