#1498 Request to add/enable epel 6 branch
Closed None Opened 8 years ago by irina.

I would like to add python-qpid, qpid-cpp, qpid-qmf, qpid-tests, qpid-tools and rubygem-qpid_messaging packages to EPEL 6. These packages were deprecated in RHEL 6.4 and should be eligible for EPEL 6 now. We have applications/open source projects depending on them (they are forced to build their own copy of EPEL 6 packages now). I reviewed my request with Subhendu and Siddharth (RHEL Product Managers), and they do not object to this.

I have rel-eng ticket for this:
https://fedorahosted.org/rel-eng/ticket/6291

Parts of my request were denided, others ignored.

Fedora rel-eng team makes decisions based on policy that prohibits EPEL 6 builds for packages included in RHEL 6.

For example:
(1) limb changed irina's branch request for qpid-tools in el6 from Awaiting Review to Denied with message: Present in RHEL6

I have no idea what this means, I am assuming he meant RHEL 6:
(2) limb changed irina's branch request for qpid-tests in el6 from Awaiting Review to Denied with message: Present in EPEL

Please review my request and ask rel eng team to complete it.


It has been less than 48 hours since you approached rel-eng about this. I think that's rather too short a time to try to escalate this to FESCo.

OK, just would like to explain why this is important.

----- Original Message -----
From: "Brian Bouterse" bbouters@redhat.com
To: "Ken Giusti" kgiusti@redhat.com, "Mike Cressman" mcressma@redhat.com, "Ted Ross" tross@redhat.com, "Irina Boverman" iboverma@redhat.com, "Michael Hrivnak" mhrivnak@redhat.com
Sent: Wednesday, November 11, 2015 6:18:37 PM
Subject: Making Qpid available in epel6 recap

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Not everyone is familiar with the background of this issue, so here is
a somewhat brief summary.

== The technical history ==
When upstream Pulp starting using Qpid (early 2014), we built cpp
server and python client 0.26 for EL6 in koji.katello.org (where Pulp
is built) and we have been included it in our Pulp repo ever since
0. When installing those Qpid packages, you're required to enable
epel6 because some dependencies come from epel6. On Oct 1 2015 (IIRC),
the qpid-proton packages in epel6 were rebased onto a new version
which removed the dependency libqpid-proton.so.2 and replaced it with
a newer one libqpid-proton.so.3. As such, the Qpid broker packages
Pulp provides cannot be installed on EL6, and there are no other
public, blessed Qpid builds available to the upstream Pulp community.
This is tracked in upstream Pulp as 1. We have been contacted by
multiple users regarding this issue.

== Why this matters ==
Upstream Pulp defaults to using Qpid, but through easy config changes
works with RabbitMQ. One way for EL6 Pulp users to workaround the
issue 1 is to switch to RabbitMQ. Upstream Pulp users are free to
choose what to use as their broker, but Red Hat products derive the
most testing value when upstream users choose Qpid. Pulp+Qpid is
heavily used in current or actively developed Red Hat products
including Satellite 6, RHUI, RHCI, RCM (the CDN folks), and probably
more places in the future. The longer this is broken on EL6, the more
upstream users will switch to RabbitMQ which decreases the testing
benefit to the downstream products.

Irina, I saw you contacted the RHEL team about getting the epel6
builders enabled. Thanks a lot for that and your ongoing work to
resolve this. This note serves to catch others up who aren't familiar
with Pulp or this dependency issue.

https://repos.fedorapeople.org/repos/pulp/pulp/stable/2.6/6Server/x86_64
/

I'm surprised RHEL PM agreed to this anyway. While qpid related packages might be deprecated for the main RHEL 6 product, even the latest 6.7 Technical notes say they are supported for the MGR product:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.7_Technical_Notes/

"Red Hat MRG-Messaging customers will continue to receive updated functionality as part of their regular updates to the product."

Also, with the qpid packages being present in older RHEL 6 versions, that means RHEL 6 users may have them installed on their systems still and would suddenly be getting updates via EPEL if that was in use. This whole situation is rather messy.

I replied to you on the rel-eng ticket.

I don't feel there's anything for FESCo to do here, so personally I would close this ticket as invalid, but it's up to you I guess.

A sub-set of these packages was distributed by RHEL 6, and was deprecated in 6.4. Please
see this bz: https://bugzilla.redhat.com/show_bug.cgi?id=860872

All these packages are now distributed by product MRG. EPEL 6 packages will be different
from MRG packages (very limited patches, no product level testing), and to eliminate any confusion,
I will add "epel" to the NVR. We already have all these packages in EPEL 7, and we are distributing
MRG/RHEL 7 packages as well.

Regards, Irina.

Yes, I see where thats mentioned, but it doesn't seem to actually be the case? Unless we are syncing rhel6 incorrectly somehow the packages are still there.

The rhn web interface seems to agree:

{{{
Red Hat Enterprise Linux 6 Server (RPMs)
python-qpid Python client library for AMQP Download Latest
qpid-cpp-client Libraries for Qpid C++ client applications Download Latest
qpid-cpp-client-ssl SSL support for Qpid clients Download Latest
qpid-cpp-server An AMQP message broker daemon Download Latest
qpid-cpp-server-ssl SSL support for the Qpid daemon Download Latest
qpid-qmf The Qpid Management Framework Download Latest
qpid-tests Conformance tests for Apache Qpid Download Latest
qpid-tools Management and diagnostic tools for Apache Qpid Download Latest
}}}

Perhaps they didn't get blocked right in the main server rpms channels?

To the best of my knowledge, RHEL never removes packages from RHN after they have been shipped. But since RHEL 6 no longer supports/updates these packages, there is no conflict in offering updated packages in EPEL 6. EPEL 7 already includes them all. What other information do you need to move this request forward?

I would like to discuss this at the FESCO Meeting today, Nov. 18, 2015.
Regards, Irina.

I don't see anything is there to discuss for this ticket. All I see is that rel-eng ticket is not yet given any conclusion so you should wait for it.

Even if this ticket comes to discussion in the meeting, I have no information how these package changes works between RHEL6 and EPEL6. Its totally Fedora and RHEL rel-eng people work to find out what is the reason for not having requested packages in EPEL6.

I do not see any progress on my ticket, nor any requests for additional information. I think FESCO may need to review my request and decide what should be done.

I don't understand why are you in so much rush? May I know why is this became so much important for you? If its just that those packages are not part of recent RHEL6.x release and you want to provide these deprecated packages to someone then why not create a Copr repository and build there packages till Fedora rel-eng fix the issues?

We discussed this during today's FESCo meeting, and Irina said that she will try to work this out with the PEL Steering Committee.

Login to comment on this ticket.

Metadata