Branching Asterisk for EPEL

Thorsten Leemhuis fedora at leemhuis.info
Fri Dec 21 15:03:43 UTC 2007


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.

Cu
knurd




More information about the epel-devel-list mailing list