Bug 1159351 - Retire cmake28 from EPEL6
Summary: Retire cmake28 from EPEL6
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: cmake28
Version: el6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-10-31 16:17 UTC by Orion Poplawski
Modified: 2015-11-18 00:57 UTC (History)
6 users (show)

Fixed In Version: cmake28-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-18 00:57:44 UTC
Type: Bug

Attachments (Terms of Use)

Description Orion Poplawski 2014-10-31 16:17:31 UTC
Description of problem:

cmake has been updated to in RHEL6.6, so we don't need cmake28 anymore.

Comment 1 Richard Shaw 2014-10-31 16:20:34 UTC
Wow, did expect that...

I wish we could have come up with a less "versiony" name, it would have been nice to be able to upgrade this package to the 3.0 series.

I don't suppose that the new RHEL package will have a virtual provides for cmake28? It would be nice not to have to go fix all my spec file conditionals.

Comment 2 Rex Dieter 2015-01-08 14:54:57 UTC
It does not contain any cmake28 macros or provides, unfortunately (but neither did fedora's pkg that it was based upon)

Comment 3 Dave Johansen 2015-06-23 00:01:52 UTC
One thing standing in the way of retiring cmake28 is all of the EPEL packages that use cmake28. It would be nice if the base RHEL package had a virtual provides and symlink for cmake28 because then the EPEL package could be retired would any changes needed in the any of the existing packages.

Can that sort of thing be handled as part of this bugzilla? Or should a separate bugzilla requesting that change be created?

Comment 4 Orion Poplawski 2015-06-23 15:15:19 UTC
If you want to make such a request, do it in a separate BZ against RHEL6 cmake.

Comment 5 Jonathan Underwood 2015-06-23 15:20:54 UTC
Hi folks, sorry I dropped this package sometime ago now, as I no longer have access or reason to use rhel6/sl6/centos6 machines. I've re-assigned the bug accordingly, hopefully Jon will pick it up.

FWIW it'd be nice if upstream added facility in the build system to rename the binary with a suffix, such that the manual patching I did doesn't have to be laboriously re-done with each release.

Comment 6 Gwyn Ciesla 2015-06-25 14:09:50 UTC
Simply adding a Provides won't do it, most of the packages that use cmake28 are modified to use the parallel-installed binaries.  Better to migrate.  Do we have a list of packages that BR it?

Comment 7 Dave Johansen 2015-06-25 15:14:47 UTC
Wouldn't making a cmake28 symlink that points to cmake fix that?

I think finding the list of BRs will be hard (or at least time consuming):

Comment 8 Gwyn Ciesla 2015-10-29 15:44:00 UTC
I think reducing this package to just a symlink is ok.  Any objections?

Comment 9 Orion Poplawski 2015-10-29 16:15:29 UTC
Seems reasonable.

Comment 10 Fedora Update System 2015-10-29 17:39:23 UTC
cmake28- has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-2a8f0998b2

Comment 11 Fedora Update System 2015-11-01 16:47:33 UTC
cmake28- has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update cmake28'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-2a8f0998b2

Comment 12 Fedora Update System 2015-11-18 00:57:40 UTC
cmake28- has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.

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