On Fri, 2008-07-25 at 18:34 +0300, Faidon Liambotis wrote: > Tim Retout wrote: > > The same method could be used to move more non-core asterisk dependencies > > into > > 'Recommends'. These would still be installed by default, but could be > > removed by the administrator. > There is no way we're going to do that; I believe it is the wrong way > and my gut tells me that it may also be a policy violation, but I > haven't checked.
Well, policy 7.2 says that 'Recommends' is a strong but not absolute dependency, and 'Depends' are the absolute ones. I think that many of the asterisk 'Depends' fall into the former rather than the latter; not every asterisk installation requires every asterisk dependency. For instance, I can see asterisk dependencies on libpq5, libsqlite0, unixodbc, libpri1.0, libsnmp15... if someone is just using SIP, they may well not want to have all these other dependencies installed. Recommended packages are still installed by default with both apt-get and aptitude, so this should not break anyone's installation. > Splitting chan_vpb to a different package is something we can discuss > though. We've done this before for chan_h323, it's only fair to consider > it for chan_vpb. Or that would work. :) So long as we can avoid splitting asterisk into dozens of packages, as discussed on #459244. > Besides the obvious "bloat" of having libvpb installed, do you have any > other issues with it? I've chatted to Ron on IRC, and suspect the crashes our customer experienced were a corner case not caught by the patch to #466729 in the version of asterisk that I backported to etch. They may well be fixed in Debian by now. -- Tim Retout <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]