Bug 681537

Summary: Rebase spice-client to 0.8.x for connectivity with RHEL-6 hosts
Product: Red Hat Enterprise Linux 5 Reporter: Hans de Goede <hdegoede>
Component: qspice-clientAssignee: Marc-Andre Lureau <marcandre.lureau>
Status: CLOSED NOTABUG QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.7CC: acathrow, bgollahe, cfergeau, cmeadors, dblechte, lkocman, marcandre.lureau, mkenneth, sandmann
Target Milestone: rcKeywords: Rebase
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-01 16:04:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 612967    

Description Hans de Goede 2011-03-02 14:10:05 UTC
The spice protocol has changed with newer releases, in order for RHEL-5 machines to be
able to connect to spice instances hosted on RHEL-6 the spice-client needs to be rebased to the
0.8.x series.

This request does not include adding smartcard (cac) support, as that would require adding
libcacard as a new component to RHEL-5).

Comment 2 Hans de Goede 2011-03-02 14:43:55 UTC
Soren, we will need pixman in RHEL-5 for the rebased client, which we don't
have so far. We do have the qpixman fork, which we need to keep for the
spice-server. We could put a private copy of pixman inside the spice-client
package, or do it properly as a separate package. A problem with doing it in a
separate package could be a soname conflict with the qpixman package (I didn't
check). How do you want to do this ?

Comment 3 Søren Sandmann Pedersen 2011-05-17 18:46:26 UTC
I'd suggest keeping it as a private copy in the spice-client package.

A separate package might be cleaner, but we can't use the code anywhere else.

Comment 4 RHEL Program Management 2011-05-31 15:49:02 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 5 Marc-Andre Lureau 2011-06-29 12:06:04 UTC
Hi,

I have been asked to look into packaging spice-client 0.8 for rhel5. I managed to build it without much problem, based on the Fedora specs. Here is what we could do:

- spice-protocol can be added without issue I suppose (0.8.0)

- pixman doesn't conflict with qpixman, so we can just introduce it also (0.22)

- spice-client doesn't conflict with qspice-client (which installs spicec under /usr/libexec/spicec). But to make sure it's picked by spice-xpi, we need to remove qspice-client. Any idea how to achieve this with spec fields? 

- upgrade spice-xpi

Does that sound like a plan?

Comment 6 Christophe Fergeau 2011-06-29 14:08:08 UTC
(In reply to comment #5)
> - spice-client doesn't conflict with qspice-client (which installs spicec under
> /usr/libexec/spicec). But to make sure it's picked by spice-xpi, we need to
> remove qspice-client. 

Out of curiosity, what happens if qspice-client is not removed? spice-xpi will favour the old client over the new one? Or it's just that both clients aren't parallel installable?

> Any idea how to achieve this with spec fields? 
> 

If you consider that the new package is a drop-in replacement for the old one, an Obsoletes (+ some Provides from the old package if needed) is what makes the most sense. If you don't consider both packages as equivalent, but don't want to allow the user to have it both at the same time, I'd go with a Conflicts. In this case, when trying to install the new client, the user would be asked to confirm he wants to remove the old one.

> Does that sound like a plan?

Sounds good to me once we know what we want to do with the client upgrade.

Comment 7 Marc-Andre Lureau 2011-06-29 14:56:06 UTC
(In reply to comment #6)
> 
> Out of curiosity, what happens if qspice-client is not removed? spice-xpi will
> favour the old client over the new one? Or it's just that both clients aren't
> parallel installable?

spice-xpi favours /usr/libexec/spicec, which is qspice-client.

so we can either enforce remove qspice-client or keep them both installed and let the user decide.

Comment 8 Christophe Fergeau 2011-06-29 15:06:48 UTC
> (In reply to comment #6)
> 
> spice-xpi favours /usr/libexec/spicec, which is qspice-client.
> 
> so we can either enforce remove qspice-client or keep them both installed and
> let the user decide.

Since the last step in your plan is to upgrade spice-xpi anyway, we have the option to allow both clients to be installed and patch spice-xpi to favour the newer client.

Comment 9 Lubos Kocman 2011-07-01 07:59:58 UTC
(In reply to comment #5)
> - spice-client doesn't conflict with qspice-client (which installs spicec under
> /usr/libexec/spicec). But to make sure it's picked by spice-xpi, we need to
> remove qspice-client. 


sudo rpm -ql spice-client
/usr/bin/spicec
/usr/libexec/spicec         # See this
/usr/share/doc/spice-client-0.8.0
/usr/share/doc/spice-client-0.8.0/COPYING
/usr/share/doc/spice-client-0.8.0/NEWS
/usr/share/doc/spice-client-0.8.0/README

Comment 11 Marc-Andre Lureau 2011-07-04 19:25:56 UTC
Successfully tested Spice update against rhevm 2.2 XP guest with USB share.

Short plan:

- add spice-protocol (bug 718811)
- add pixman (bug 718810)
- add spice-client (bug 681537 and bug 718817)
- update spice-xpi (bug 612967)
- update spice-usb-share (bug 718816)

Comment 13 Brian Gollaher 2011-12-01 16:04:12 UTC
This BZ was only for reference as spice-client was added to the 5.8 release.