Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Minor
-
Resolution: Incomplete
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Build-System, Packaging-Debian
-
Labels:
-
Environment:Linux lenny 2.6.31-1-686 #1 SMP Sun Nov 15 20:39:33 UTC 2009 i686 GNU/Linux
Debian GNU/Linux "unstable" (sid)
-
CPU Architecture:x86
-
Kernel:Linux
-
Userland:GNU/Linux
-
lsb_release:
-
Compiler:gcc
-
FreeSWITCH GIT Revision:16111
-
GIT Master Revision hash::well, this was yesterday's snapshot...
Description
apr
apr-util
curl
iksemel
libsndfile
pcre
portaudio
sofia-sip
speex
sqlite
spandsp
srtp
tiff
udns
yaml?
In addition, the following are downloaded during the build process and built on the fly: celt-0.7.0-1, json-c-0.8, lame-3.97, libmemcached-0.32, libshout-2.2.2 and mpg123
That will keep freeswitch from being bundled with the next Debian release. I really appreciate the work that has been done here to try to package FreeSWITCH to Debian, but as it stands, the package cannot enter the archive for three reasons:
1. it bundles copies of code already shipped in other packages (this is the issue at hand here)
2. it installs files in a non-standard location (/opt, i'll open a separate issue about this)
3. it packages non-free components (mpg123 and lame come to mind, there may be others, that's a Debian issue that doesn't have to be addressed here)
As it stands, the issue I'm wishing to address here is #1. The issue is twofold:
a. we need to be able to build freeswitch by linking to existing libraries, not the bundled ones
b. ideally, we would need a reduced source distribution that wouldn't bundle those libraries
I understand the wish for the developers here to ensure a controlled environment in the distribution of the software, but really, a 75M archive is way too big for freeswitch. This build system will impede inclusion in Debian, but I suspect it will be a problem in other distributions as well.
Before build, the freeswitch-specific code only makes 279M of the total uncompressed 364M of source code. After build, that's 482M out of 710M. Really, that should be factored out.
But for the resolution of this issue, I think we can settle with just fixing the build system by adding a make target that would use existing libraries... Then the debian/rules file can be fixed to use that target.
I would understand if you guys don't want to change the build system that way, in which case that would mean the debian package would need to divert away from the standard build system, which will involve duplicate work and more confusion, so I'd rather avoid that.
The Debian packaging effort takes place here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389591
Thanks and happy new year.
Attachments
Issue Links
- is related to
-
ESL-86 Move libs/esl to a proper autoconf for it and all its submodules.
-
- In Progress
-
-
FS-6542 Switch Portaudio to system libs, getlib on Windows
-
- Closed
-
-
FS-3815 fs_cli: enable new features on xterm
-
- Closed
-
-
FS-4617 Debian distro missing FreeSWITCH?
-
- Closed
-
- is the master task for
-
FS-6346 Upgrade windows build to use curl 7.35.0 via getlib
-
- Closed
-
-
FS-6347 Upgrade windows build to use pcre 8.34 via getlib
-
- Closed
-
-
FS-6348 Upgrade windows build to use speex 1.2rc1 via getlib
-
- Closed
-
-
FS-6349 Upgrade windows build to use sqlite 3.8.4.1 via getlib
-
- Closed
-
- relates to
-
FS-5681 Bundled pcre breaks mod_rayo (and core?) on Fedora
-
- Closed
-
-
FS-6149 Update version of libcurl
-
- Closed
-
1.
|
Depend on system libtiff |
|
Closed | Mike Jerris |
|
2.
|
Use upstream libsrtp |
|
Closed | Mike Jerris |
|