[SR-Users] create own packages for some modules

[Daniel-Constantin Mierla]

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

On 21.02.19 10:44, Sergey Safarov wrote:
> 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 at gmail.com <mailto:miconda at 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.so
>>     db_text.so
>>     rtpengine.so
>>     rtpproxy.so
>>     sipcapture.so
>>     siptrace.so
>>     sipt.so
>>     sms.so
>>     smsops.so
>>     ss7ops.so
>>
>>     https://github.com/kamailio/kamailio/issues/1862
>>
>     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 <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com <http://www.kamailioworld.com>
>     Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com <http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190221/0cab1264/attachment.html>