FAQ Search Today's Posts Mark Forums Read

» Linux Archive
Home
New Posts
Search
FAQ


Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 12-21-2007, 03:03 PM
Thorsten Leemhuis
 
Default Branching Asterisk for EPEL

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.

Cu
knurd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2007, 03:12 PM
"Jeffrey Ollie"
 
Default Branching Asterisk for EPEL

On 12/21/07, Thorsten Leemhuis <fedora@leemhuis.info> wrote:
>
> 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.

Yeah, I don't really want to get into maintaining a copy of speex - I
think that I'll poke the RHEL speex maintainer and see if we can't
work something out. If that doesn't work we'll have to wait for RHEL6
to branch Asterisk.

Jeff

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 12-21-2007, 03:41 PM
Mike McGrath
 
Default 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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 04:44 AM.

VBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org