Branching Asterisk for EPEL

[Mike McGrath]

Thorsten Leemhuis wrote:
> On 21.12.2007 15:45, Jeffrey Ollie wrote:
>   
>> On 12/21/07, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>>     
>>> On 21.12.2007 05:38, Mike McGrath wrote:
>>>       
>>>> Michael Stahnke wrote:
>>>>         
>>>>> On Dec 20, 2007 1:19 PM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
>>>>>
>>>>>           
>>>>>> I've had a number of requests to branch the Asterisk packages that are
>>>>>> now (finally) in F-7+ for EL-4 and EL-5.  Most of the dependencies
>>>>>> have been (or soon will be) taken care of. The one problematic package
>>>>>> is speex. The Asterisk package requires speex version 1.2 which is
>>>>>> available in Fedora 7 and onwards.  However, speex in RHEL5 is at
>>>>>> version 1.0.5.  Would it be acceptable to create a speex12 package in
>>>>>> EPEL so that Asterisk can be branched?  The speex12 package would be
>>>>>> for EL-4 and EL-5 only since RHEL6 will presumably provide speex 1.2
>>>>>> itself.
>>>>>>             
>>>>> Can a bug be filed with RHEL and have them bump/backport the required
>>>>> features for Speex in a future update?
>>>>>           
>>>> If possible, I think this is the best route.  Won't hurt to try it.
>>>>         
>>> +1 -- but that could take a while. If it takes to long or if it looks
>>> like it won't happen then I'd we should consider to ship a newer speex.
>>> But we should never ever disturb the RH bits, thus the speex libs should
>>> not be in the default dynamic linker path, as then other packagers
>>> linked against speex might use it (or has it a differnt .so name?) .
>>>       
>> Yeah, I haven't looked at the code yet, but I was hoping that it would
>> be relatively easy to make a speex12 package that would be parallel
>> installable with the RHEL speex package and you would need to
>> -lspeex12 instead of -lspeex.
>>     
>
> k; the biggest problem with this scheme is: what if other packages want
> to use a similar tricks when they need a new gtk, qt, <insert other
> libs>. That could soon become a maintenance pita and a kind of second
> library layer ontop of (or in parallel) the libs from RHEL, which afaics
> nobody wants. Thus we might need to limit this and put some hurdles in
> the way; something like "such packages must be approved by the EPEL SIG
> in a meeting" or something like that.
>   

the initial idea for this came from sqlite which has had multiple 
versions in at one time in the past.  Whether or not thats a good thing 
or not I don't know :)

    -Mike