I thought you want to get the feedback from users perspective. The tracker is mainly for developers.
Once the discussion here is concluded or nothing happens with it for a while, then someone can summarize what was suggested from users perspective and put it on the tracker. I don't think duplicating everything on the tracker makes sense, it is not a bug, but a feature request.
As you started on both places, you should cross reference there, as you pointed the link to issue tracker here.
In general is not good to have the discussion about same topic on
different places. Of course, we crosspost announcements and
general information messages, otherwise is better to focus on
debating something in a single place. I think this is a topic more
for users than for developers, to see if there is interest. Then
the developers can decide if it is feasible with the constraints
we have from distros (as I mentioned debian in the previous
message).
Cheers,
Daniel
Thanks Daniel for response
Sure packaging rules must be same for all dists.
Could you make same comment at https://github.com/kamailio/kamailio/issues/1862
This will allow track this request
чт, 21 февр. 2019 г. в 12:31, Daniel-Constantin Mierla <miconda@gmail.com>:
Hello,
On 21.02.19 07:39, Sergey Safarov wrote:
Current kamailio package (checked via RPM) is contains lot of modules. Some of this is not important to include in every kamailio installation. May be create own packages for this modules and other in next 5.3 branch?Modules examples:
benchmark.so
db_cluster.sodb_text.sortpengine.sortpproxy.sosipcapture.sosiptrace.sosipt.sosms.sosmsops.soss7ops.so
use of such modules is a matter of deployment type and for example, for residential services, rtpengine or rtpproxy are like a must. I also use often benchmark module to track execution of some operations (like http queries). Also, siptrace is rather common in what I deal with.
IMO, it is hard to make a selection on usage or personal preferences. The rule was that was has same dependencies as core, they should be packaged together.
Actually there was a discussion to add more to the main package, from those with additional dependencies, but very used (like tls, ...) -- it might be on issue tracker as well.
Then, Victor Seva mentioned at some point in time that in debian is better to keep modules groupped as many as possible, because introducing a new package in the official distro requires a complex process of review for license, etc...
Overall, if there is a decision to regroup some modules in different packages, I would like to follow the same for both debs and rpms, otherwise installation guidelines can end up to be different and can become confusing.
Cheers,
Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com