Bug 818488
Summary: | voms-api-java requires old jakarta-commons-* packages | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stanislav Ochotnicky <sochotni> |
Component: | voms-api-java | Assignee: | Mattias Ellert <mattias.ellert> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | mattias.ellert |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-14 16:37:51 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: |
Description
Stanislav Ochotnicky
2012-05-03 08:39:26 UTC
Why? The choice to Require and BuildRequire jakarta-* rather than apache-* was deliberate. The apache-* packages Provides the jakarta-* names, but the jakarta-* packages don't Provide the apache-* names. Requiring jakarta-* will always work. Requiring apache-* will fail on old distributions like EPEL 5 and EPEL 6, so insisting on using the apache-* Requires for newer distributions would result in introducing more conditionals in the spec file to use different Requires for different distributions. I currently see no need to do this, since the more simple solution to use the same Requires everywhere works fine. Unless you know of any plans to drop the jakarta-* Provides from the apache-* packages? No reply from reporter - closing. Hmm, seems like I missed this from my mail queue and then...oh well. Anyway, the jakarta provides in apache commons were supposed to be temporary for the duration of few fedora releases (which they were). I'd like to eventually get rid of them. On one hand I prefer to keep specs for EPEL/Fedora separate since they tend to diverge anyway. But that's not my call for your packages. However keeping those provides for another 7 or so years...i.e. 14 fedora releases, seems...excessive. I don't like it, because it means it will creep into another RHEL release and the cycle will never end. We will have to keep that old provides indefinitely. voms-api-java-2.0.10-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/voms-api-java-2.0.10-2.fc16 voms-api-java-2.0.10-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/voms-api-java-2.0.10-2.el6 voms-api-java-2.0.10-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/voms-api-java-2.0.10-2.fc18 voms-api-java-2.0.10-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/voms-api-java-2.0.10-2.el5 voms-api-java-2.0.10-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/voms-api-java-2.0.10-2.fc17 voms-api-java-2.0.10-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. voms-api-java-2.0.10-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. voms-api-java-2.0.10-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. voms-api-java-2.0.10-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. |