[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Branching Asterisk for EPEL



Thorsten Leemhuis wrote:
On 21.12.2007 15:45, Jeffrey Ollie wrote:
On 12/21/07, Thorsten Leemhuis <fedora 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 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]