[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#389591: status update



So, I had a lenghty discussion with upstream that is summarized here:

http://jira.freeswitch.org/browse/FSBUILD-227#action_18819

Basically, things are not as bright as I thought they were. Looking back
at the original plan:

 1. get rid of the duplicate libraries, which involves:
   a. asking help upstream, which will imply:
   b. removing the library code from the tarball, and;
   c. link with existing libraries.
 2. move the binaries out of /opt:
   a. try to move to /usr/lib/freeswitch, then;
   b. split configuration files, libraries and binaries in proper paths
   (/etc/freeswitch, /usr/lib, /usr/bin, etc)
 3. remove non-free bits (mpg123 and lame on the radar right now)

2 and 3 shouldn't be a problem. 3 will be a patch local to Debian
(although a flag to disable those libraries would probably be accepted
upstream). 2 is being worked on in:

http://jira.freeswitch.org/browse/FSBUILD-220

and

http://jira.freeswitch.org/browse/FSBUILD-228

1 is much harder. The problem is that the duplicate libraries have a
very good reason for living in the FreeSWITCH tree: they fix stuff. They
have been working on those to fix crashes and performance issues all
over the place. Simply linking against system libraries (1.c) will just
not work and FreeSWITCH just crashes on startup when compiled like this
(according to MikeJ).

FreeSWITCH will probably keep on bundling patched third-party libraries
and *require* those to function properly, for the foreseeable future 

This means that those libraries will have to be in some cases repackaged
to comply with the Debian Policy (section 4.13). A good example is
libiax: upstream is refusing the patches, so there's no way for those
guys to make libiax work for them and they made a fork. In the long run,
they will try to make that fork official and switch to a different
namespace so that those forks can be officially packaged by distros.

In other cases, it's just a matter of merging the patches into the
third-party libraries upstream. A good example is APR: the FS folks have
implemented fixes for threaded environments and memory allocation that
will eventually be accepted in APR, but since they break the API, that
won't happen before 1.4 is released (and which is not in Debian yet).

All that said, our roadmap here becomes:

 1. fix the duplicate code problem, which involves:
    a. namespace separation between forked and official libraries (e.g.
       libiax)
    b. upstream merge (and release!) of fixes for non-forked libs (e.g.
       APR)
    c. dropping the other libraries (e.g. sqlite)
 2. move out of /opt:
    a. create flags for various locations
    b. use those flags in the official debian package
 3. remove non-free bits

1 is followed up in http://jira.freeswitch.org/browse/FSBUILD-227

2.a is http://jira.freeswitch.org/browse/FSBUILD-220

2.b is http://jira.freeswitch.org/browse/FSBUILD-228

So there we are.

-- 
Antoine Beaupré
Réseau Koumbit Networks
+1.514.387.6262

Attachment: signature.asc
Description: Digital signature


Reply to: