On Tue, Jan 19, 2016 at 9:34 PM, George Joseph <[email protected]> wrote:
> > > On Tue, Jan 19, 2016 at 7:52 PM, Jeffrey Ollie <[email protected]> wrote: > >> OK, I'm going to take a deep breath here... >> >> The distributions policies against embedding libraries and statically >> linking code isn't some arbitrary policy. It's a hard-earned best practice >> that's been proven over and over. >> >> I get that it's "easier" to not work with others to solve problems and to >> basically do a soft-fork of the pjproject code and embed it into Asterisk >> and get it all set up "just so". >> >> This is however, IMNHSO, short-sighted, anti-social behavior. Asterisk >> used to be pretty bad in this regard but recently has been much much >> better. I really don't want to see the clock turned back. >> >> My recommendations: >> >> 1) Work with the pjproject upstream to convert problematic compile-time >> options into runtime configurable options. That way multiple consumers of >> the library can get pjproject to work the way that they need it to without >> recompiling it. >> >> 2) If #1 isn't feasible, work with the pjproject upstream to set defaults >> for compile-time options that work better for Asterisk. >> >> 3) Add runtime instrumentation to pjproject so that Asterisk can >> determine if pjproject is configured correctly for use with Asterisk at >> runtime. >> >> 4) Work with the distro maintainers to get pjproject packaged with the >> compilation options that work best with Asterisk. >> >> 5) Write up good docs on how to compile pjproject from source for use >> with Asterisk for those folks that like to compile with source. Do your >> best to make sure that it's easily findable in Google searches, as well as >> linked to in the appropriate places from the Asterisk documentation. >> >> -- >> Jeff Ollie >> >> Philosophically speaking, I agree with you 100%. Unfortunately, when > philosophy meets the real world, things often don't go as planned. The > reality is that the majority of people who use Asterisk don't care whether > pjproject is statically or dynamically linked or whether it's bundled or > not. They just want it to work and when it doesn't they want a solution. > They want "1 throat to choke", they don't care whether it's Asterisk's > fault or pjproject's fault and they especially don't want to have to figure > out which it is themselves. A quick search in the RedHat Bugzilla shows > that only 3 tickets were opened against Asterisk in the past 2 years by non > RedHat employees so it's certainly not the packagers they're asking for > help. It's the Asterisk team that's on the hook. > > While your suggestions can and should be taken and can help in the long > term, it's not enough. In the end, it's about the people who produce the > software trying to help the people who use it. I sympathize with the > plight of the packagers, and if the packagers were fielding the issues I'd > sympathize even more, but that's not the case and I always have issues with > black-and-white policies that leave no room for exceptions or the > application of common sense. > > >> >> Oh, of course, none of this is to say packagers CAN'T build and dynamically link Asterisk. I'd even add ./configure options to make that as easy as it is today. I would suggest however, that the JIRA ticket process require that a user be running the statically linked version to open a ticket and that the support guidelines highlight that the team may not be able to effectively provide support when Asterisk is installed via some other means. > -- >> _____________________________________________________________________ >> -- 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 >> > >
-- _____________________________________________________________________ -- 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
