[asterisk-dev] Proposal to bring pjproject back into the fold

[Matthew Jordan]

On Wed, Jan 20, 2016 at 11:04 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>
wrote:

> On Wed, Jan 20, 2016 at 09:49:32AM -0600, Matthew Jordan wrote:
> > On Wed, Jan 20, 2016 at 8:22 AM, Jared Smith <jaredsmith at jaredsmith.net>
>
> > So why is pjproject such a pain?
> >
> > There's probably a number of reasons, and I'm probably forgetting some,
> but
> > I'd boil the top ones down to the following:
> >
> > * pjproject embeds third party libraries.
> >
> > Some of those third party libraries are also libraries that Asterisk can
> > use; if Asterisk needs to use them, you have to tell pjproject to not use
> > its embedded version. While it is easy to say that pjproject should "just
> > not do that", that misses the original - and still one of the most
> common -
> > use cases of pjproject; namely, as an embedded systems library. For
> people
> > building SIP devices on embedded platforms, having embedded versions of
> > GSM, SRTP, and other useful libraries is actually advantageous. Packages
> > are not usually available for, say, VxWorks, and if I know pjproject can
> be
> > built using my esoteric toolchain, I don't have to try and make libsrtp
> > build as well with it.
> >
> > As a result, pjproject is highly unlikely to ever remove their embedding
> of
> > third party libraries, despite our attempts at convincing them to do
> that.
> > They serve *more* than just the Asterisk project, and our needs are not
> > always going to match 100% with theirs.
> >
> > The implications of that are that we're going to need to work around
> and/or
> > deal with the third party libraries they embed in some fashion.
>
> I'm not sure what your exact issue is here.
>
> Is there any specific library that pjproject currently embeds that can't
> be trivially disabled? Do you think there is an issue with pjproject not
> defaulting enough to using system libraries where possible?
>
> > * pjproject static/shared libraries is confusing for many people
> >
> > It is not uncommon for people to build static libraries of pjproject the
> > first time around (missing the instructions to not do that), install
> them,
> > and run Asterisk. Asterisk then will crash or do something terrible. They
> > will then attempt to install the shared object libraries, not removing
> the
> > static libraries. Asterisk will still run, and now crash in a different
> > fashion. They will then attempt to remove the static libraries, and now
> > Asterisk will complain that it can't find pjproject because you're using
> > RHEL and your pkg-config path isn't set up correctly.
>
> Hang on. This is RHEL. A stable platform. Why can't they just use
> pjproject packages and be done with it?
>
>
The same question could be asked of why they choose to build Asterisk from
source.

I won't get into why a user may choose to build from source versus install
from packages, nor am I going to blame a user for choosing to do so. The
user experience in that situation is sub-optimal.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160120/f608e5c0/attachment.html>