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-client | Assignee: | Marc-Andre Lureau <marcandre.lureau> |
Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 5.7 | CC: | acathrow, bgollahe, cfergeau, cmeadors, dblechte, lkocman, marcandre.lureau, mkenneth, sandmann |
Target Milestone: | rc | Keywords: | 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
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 ? 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. 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. 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? (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. (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.
> (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.
(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 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) This BZ was only for reference as spice-client was added to the 5.8 release. |