[asterisk-dev] CentOS packaging

[Matthew Jordan]

On Wed, Feb 26, 2014 at 7:48 AM, Jared Smith <jaredsmith at jaredsmith.net> wrote:
> On Tue, Feb 25, 2014 at 3:23 PM, Ben Langfeld <ben at 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