[asterisk-dev] Corydon76 Issue Deleted: 0006925, 04-28-06 17:49 Corydon76 Issue Deleted: 0006920

[Denis Smirnov]

On Mon, May 01, 2006 at 04:00:15PM -0500, Kevin P. Fleming wrote:

>> Simple concept attached.
KPF> Which will fail on many systems, especially those where the library is
KPF> not installed where you expect it to be.

I know. It's _concept_.
It's not fail, because -rpath used and library installed in
/usr/lib/asterisk. But using hardcoded path is not "the right way", I
know.

KPF> Again, I ask: describe the _value_ of doing this, not the mechanics of
KPF> doing it. We aren't going to change the build process just because it's
KPF> easy (or relatively so), there has to be a valid reason. Do you realize
KPF> that changing this to install a library means that distros will likely
KPF> have to start packaging the library and the binary in separate packages,
KPF> along with creating a 'libasterisk-dev' package for building external
KPF> modules, etc.? That's a lot of work for us and them, if we can't
KPF> describe a very good reason for doing it.

All distros need to create libasterisk-dev package for
/usr/include/asterisk. Adding library to this packages not so hard.
And for mantainers it has a feature -- autotesting of unresolved symbols.

Reverse symbols provides is a nasty hack, that works, but make autotesting
and compatibility harder.

With library we can use versioning, and when we change API needed for some
module, it automagicaly would be detected. And if we change API that
doesn't need for some module, it would work ok.

-- 
JID: ds at im.seiros.ru
ICQ: 58417635 (please, use jabber, if you can)

http://freesource.info/