On 02/26/2014 02:02 AM, Tzafrir Cohen wrote:
On Tue, Feb 25, 2014 at 05:04:26PM -0500, Sean Darcy wrote:
On 02/25/2014 02:03 PM, Ben Langfeld wrote:
After a conversation with Rusty last week, I've become aware that for a
simple installation of asterisk (11) from the CentOS repositories at
http://packages.asterisk.org/centos/, the 'current' repo at
http://packages.digium.com/centos is required to satisfy the dependency
of the 'asterisk' package on 'asterisk-dahdi'.
I understand that there are licensing reasons for this package to not be
available from the community repo, and I'm not going to get into the
complexity of that, but this situation is rather odd. It's required to
add a total of three repos, from two different domains, just to do 'yum
install asterisk' and get something from this decade. This seems
excessively complex, and likely unnecessary.
Is there anything that can be done to simplify this? Is the dependency
on asterisk-dahdi really necessary? Is there a reason not to publish the
contents of the 'current' repo to all of the 'asterisk-MAJOR' repos, to
reduce the required repo-count to 1?
Cheers,
Ben Langfeld
Does there need to be a dependency on asterisk-dahdi? Asterisk works
just fine without dahdi. Can it be an "add-on" if dahdi is wanted?
Is it required to specify dahdi at compilation to use the dahdi
package later?
dpkg has not only Depends but also Recommends (packages that SHOULD BE
installed for the package to work properly, but can not a strict
dependency) and Suggests (nice-to-have provisions).
We currently have asterisk-dahdi as a Suggests.
If asterisk is built with dahdi, does it need the dahdi package? All
of the dahdi package? or just the tools? Perhaps asterisk-dahdi
could just be the tools (which would meet the Fedora criterion,
right?), and the kernel modules an "add-on" package.
Asterisk uses libtonezone from dahdi-tools (right? Just chan_dahdi?).
Asterisk-dahdi are all the modules that will not work without DAHDI
support: chan_dahdi, app_meetme, res_timing_dahdi, codec_dahdi, and a
few other minor modules.
The kernel modules are from a different package that is independent of
Asterisk. It is also a package that will not get into Fedora any time
soon. It has two licensing issues:
1. binary-only objects optionally used to build some of the modules.
2. firmware files.
(2) can be fixed in retrospect at distribution time. But (1) has to be
tended to at build time. The Debian packages thus fail to include (1)[1]
and sort-of-work-around (2) with a package in non-free[2].
[1]
http://patch-tracker.debian.org/patch/series/view/dahdi-linux/1:2.7.0.1~dfsg-1/no_firmware_download
[2] Debian's firmware policy is stricter than Fedora's, and some of the
firmwares will be legal for Fedora. The ones not currently not even
included in the Debian package will not.
Thanks for the description. I understand better now.
If I understand correctly, to build asterisk with chan_dahdi selected in
menuseelect, libtonezone from dahdi-tools is required. Once built, dahdi
and it's various modules will only work if those modules, the firmware
and the kernel modules are present. If they are not present, dahdi will
just fail to load, the rest of asterisk will work just fine. Correct?
If so, why can't Fedora (and Debian) have an asterisk package with
chan_dahdi selected, requiring libtonezone.so, which doesn't cause any
issues with the packaging criteria. This way, all users can run yum
install asterisk from the fedora repo. If they need dahdi, they will
need to specify another repo which would have a dahdi package with the
modules and firmware.
sean
--
_____________________________________________________________________
-- 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
