Bug 681537 - Rebase spice-client to 0.8.x for connectivity with RHEL-6 hosts
Rebase spice-client to 0.8.x for connectivity with RHEL-6 hosts
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: qspice-client (Show other bugs)
5.7
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Marc-Andre Lureau
Desktop QE
: Rebase
Depends On:
Blocks: 612967
  Show dependency treegraph
 
Reported: 2011-03-02 09:10 EST by Hans de Goede
Modified: 2011-12-01 11:04 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-01 11:04:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2011-03-02 09:10:05 EST
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 09:43:55 EST
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 14:46:26 EDT
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 Product and Program Management 2011-05-31 11:49:02 EDT
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 08:06:04 EDT
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 10:08:08 EDT
(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 10:56:06 EDT
(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 11:06:48 EDT
> (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 03:59:58 EDT
(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 15:25:56 EDT
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 11:04:12 EST
This BZ was only for reference as spice-client was added to the 5.8 release.

Note You need to log in before you can comment on or make changes to this bug.