On Wed, Feb 26, 2014 at 7:48 AM, Jared Smith <jaredsm...@jaredsmith.net> wrote: > On Tue, Feb 25, 2014 at 3:23 PM, Ben Langfeld <b...@langfeld.me> wrote: >> >> Unfortunately those packages are of Asterisk 1.8: >> http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/asterisk.html. That's >> a total no-go for me, I'm afraid, but thanks for the suggestion :) > > > Sure, the current EPEL packages themselves are stuck on Asterisk 1.8 (due to > EPEL policy of aiming for LTS releases of software and not upgrading major > versions), but the spec file is based on the Fedora package, which is > currently up to date with Asterisk 11. (As a side note -- Fedora hasn't > moved to Asterisk 12 because of some of the bundled library issues, > particularly around pjproject.) The spec file is at > https://apps.fedoraproject.org/packages/asterisk/sources/spec/ and that page > also lists out the various subpackages that are built, patches that are > applied, etc. > > I could easily build Asterisk 11 RPMs based on the Fedora spec file for > RHEL/CentOS 6 if you're interested. >
I'm going to preface this e-mail with the following: (1) I fully appreciate the annoyance of having embedded libraries in Asterisk. While some of those embedded libraries may be difficult to extract, some - most likely - could be removed at this point. I would love to see patches proposed for Asterisk that removed some of the external libraries (editline and mxml are two that come readily to mind). (2) The policy of any distribution is, and should be, set by that distribution. If a distribution has a policy that precludes it from including packages of Asterisk, I fully respect that. At the same time, that does not mean that said policy - even when it is well intentioned - will always make the most sense either for the Asterisk project or for projects that Asterisk depends on. That being said, I have a very difficult time understanding how Asterisk 11 can have packages for Fedora but Asterisk 12 cannot. As Tzafrir pointed out later, Asterisk 11 embeds pjproject. This embedding of pjproject includes the third_party folder, which contains many other embedded libraries. However, this inclusion of pjproject - for whatever reason - did not warrant rejecting Asterisk. Due to the demands of certain members of the Asterisk community [1], we spent a considerable amount of effort removing pjproject from Asterisk 12. This was a good thing to do: it made the Asterisk build system cleaner and resulted in numerous improvements to pjproject that have been included in the up stream distribution [2]. Today, we have a version of Asterisk that contains fewer embedded libraries, as well as a version of pjproject that can be made into packages (even if those packages are not suitable for some Linux distributions). Despite this, the decision was made that Asterisk 12 was unsuitable for packaging in the Fedora distribution, due to it using (but not strictly depending on) pjproject. While this decision ultimately rests with the packages for Fedora - and it is their decision to make - it is very hard for me to view this decision as not setting a bad precedent. This decision implies that even if we remove embedded libraries from Asterisk, if *those* libraries also contain embedded libraries or are somehow not viewed as being suitable for the distribution, we will be out of consideration for packaging. In fact, those libraries don't even have to be hard dependencies - merely using them is sufficient for being tossed out. The Asterisk project's only recourse is to take or exert substantial control on all of its dependencies - which removes nearly any benefit from using packages for said functionality in the first place. That's not something I'm interested in doing. If that is the policy of Fedora, then quite frankly, it should just stop including packages of Asterisk. There have been embedded libraries in Asterisk all the way back to version 1.0.0 - and if the Fedora packagers are going to choose to enforce a policy that requires Asterisk to not use any library that cannot be made into a suitable package, they may as well be consistent. As an aside, once I've gauged more of the difficulty of removing some aspect of the third_party library from pjproject - and I know Jared, it's been on my To Do list for way too long - we should consider other build options so that it is far easier to just remove the offending folder. If nothing else, I would expect the Asterisk project to provide a mirror of pjproject simply in case of critical bugs, and having a cleaner mirror that can be made more easily into Linux suitable packages would be nice. It seems unreasonable, however, to expect pjproject to remove that folder completely from their distribution. pjproject is built on more operating systems than just Linux. As a result, they may have to sometimes include functionality that is not available on those other operating systems. While it may be possible to produce a variant of pjproject without said folder, it may be very difficult - if not impossible - for them to remove it permanently. [1] http://lists.digium.com/pipermail/asterisk-dev/2012-November/057591.html [2] http://trac.pjsip.org/repos/milestone/release-2.2 -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
