On Sat, May 16, 2015 at 7:48 PM, Orion Poplawski <or...@cora.nwra.com>
wrote:

> On 05/15/2015 10:57 PM, Dave Johansen wrote:
>
>> On Tue, Apr 21, 2015 at 8:07 PM, Orion Poplawski <or...@cora.nwra.com
>> <mailto:or...@cora.nwra.com>> wrote:
>>
>>     On 04/21/2015 08:48 PM, Dave Johansen wrote:
>>
>>         On Mon, Apr 20, 2015 at 9:40 PM, Orion Poplawski
>>         <or...@cora.nwra.com <mailto:or...@cora.nwra.com>
>>         <mailto:or...@cora.nwra.com <mailto:or...@cora.nwra.com>>> wrote:
>>
>>              On 04/20/2015 09:32 PM, Dave Johansen wrote:
>>
>>                  I just noticed that the version of cmake that comes
>>         with RHEL 6 is
>>                  currently 2.8.12.2 and the EPEL has a cmake28 package
>>         that is at
>>                  version
>>                  2.8.11.2. I believe that RHEL 6 originally shipped with
>>         cmake
>>                  2.6 and
>>                  updated in a later point release, but I have two
>> questions:
>>                  1) Is the cmake28 a duplicate and need to be removed?
>>
>>
>>              Yes.
>>
>>
>>         Ok. Is this already being worked on? Or does a bugzilla need to be
>>         created for it?
>>
>>
>>     A quick search:
>>
>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=%3Acmake28&list_id=3417355
>>
>>     turns up: https://bugzilla.redhat.com/show_bug.cgi?id=1159351
>>
>>     There is some question as to whether or not it is worth the pain to
>>     retire.  I suppose you could also consider it pulling things away
>>     from EPEL users.  If it is kept, it probably should be updated at
>> least.
>>
>>
>> Would it be possible to create a Bugzilla and request that a virtual
>> provide for cmake28 be added to the cmake package in RHEL? I believe
>> that would allow the package in EPEL to be retired without requiring
>> changes to existing .spec files. I'm guessing that a cmake28 symlink
>> might be needed as well, but it still seems possible and a solution that
>> shouldn't have too much headache.
>>
>
> Sure, anything is possible :).   Although I don't see what the big deal
> about changing the EPEL packages would be.   If anything, it would just
> bring them back in line with the Fedora branches.
>

My concern would just be the added effort of maintaining both of them and
it falling behind like has already happened here.
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Reply via email to