Hello,
On 10/11/14 16:11, Luis Azedo wrote:
Hi Daniel,
i understand your points, i addressed both json-c and rabbitmq-c projects before doing
this and they saw no problems with that.
but we became the distributors and we face the eventual issues, so we
must agree as well. Asking original projects is fine for a
clarification, but the target is the one liable and we didn't have any
discussion on it.
I put these remarks as general information, because it will apply in all
cases when someone wants to embed something.
creating the json-c and rabbitmq-c packages for rpm
and make the constraint to build kazoo module did work for centos 6,7 and rehl 6,7, but,
this would also imply that these packages would be integrated into kamailio rpm dist so
that install of kazoo module would not fail because of missing dependencies at install
time, wouldn't this be a problem too (distributing an outside library built by us) ?
Our repository can contain something different than the distros. If
someone would want to use the redis module, then it has to use our repo.
We cannot push extra/newer versions of packages in distros.
What is built on OBS is kept in our rpm repo, not included in rpm distros.
as you know, opensuse build server doesn't not
allow (or maybe i missed that) to reference external repos like epel, but most servers
will have this repo added, won't there be a conflict with json ad/or rabbitmq at
install time?
as for the debian deb packages, as you know, wheezy or squeeze are the versions supported
at this time since jessie is still beta, right ?
Jessie is on the way to be new stable, with new packages adoption being
frozen already or more or less to be done by this time (iirc).
If we change anything radical in kamailio, with new consistent code, it
will be labeled as 'new' and won't make it in Jessie at all (even if
people there will accept embedding the libs, which is also very unlikely).
This is the stable release policy common out there, which we have with
kamailio as well. Once something is marked stable, stays with same set
of features, only bug fixes. While some people find a missing feature
annoying in an old version, there are a lot appreciating the stability.
We don't put kazoo in 4.0 or 4.1, some debian doesn't put new stuff in
wheezy, squeeze, etc...
Using a very new feature implies some risks and efforts, so using a new
version of a linux distro could be a part of it.
we are not releasing librabbitmq or json-c versions, we are releasing a kazoo-deps
library.
the libkazoo-deps does not affect other modules and will tend to disappear in future
releases and is only installed if kazoo module is.
Maybe it is better that you start
a new discussion on this mailing list,
with appropriate subject, explaining the concept you want to put in
place for packaging kazoo.
Again, all the people here are open to make the life easier for
everyone, easier distribution being one of such things, but not the
only. List the problems, the solutions you thought of and then we can
analyze if it is possible to do it, if there are better alternatives or
what is the solution we can stick to.
Cheers,
Daniel
cheers
________________________________________
From: Daniel-Constantin Mierla [miconda(a)gmail.com]
Sent: Monday, November 10, 2014 6:17 AM
To: Luis Azedo; Kamailio (SER) - Development Mailing List
Subject: Re: [sr-dev] git:4.2: kazoo : remove dependencies
On 10/11/14 14:51, Luis Azedo wrote:
reverted from 4.2 (it was a cherrypick from
master)
For the future, use '-x' with cherry-pick in order to be able to
track
easily what commits were backported.
the code is included because there are too many
issues trying to build kazoo module with existing rpm or deb, specially on deb for
released and supported versions of debian.
with this commit, i was able to create rpm for centos 5,6,7, rehl 5,6,7, opensuse 12.3,
13.1, 13.2 and deb for squeeze, wheezy, jessie, precise, trusty
the code included is to be part of kazoo module distribution, kazoo.so + libkazoo-deps.so
in deb/rpm
the code it self will be maintained by releases of kazoo module and will tend to
disappear in the future, we are just trying to give the community a working module that
people can actually build without the mess of deb/rpm dependencies.
as for the 4.2 commit, my fault, thought that this commit could go into minor release
you're planning and finally get usable deb packages.
if you still want me to revert from master i will do it
Master is ok for me until
there is a good solution agreed by most
developers.
I really appreciate your time and work to find solutions, but there
might be negative side effects, that's why we discuss on sr-dev before
pushing anything major to a stable branch.
One of the problems when including other libraries is (as pointed by
others) that we risk to get Kamailio removed from main linux
distributions. It is the standard mechanism to rely on shared libraries
and distros don't like embedding, which is understandable from many
points of view, including security, maintenance, symbol conflicts, etc.
Then importing source code requires licensing review as we become the
distributors (we have it on our repository) and we risk legal actions if
we are not sure the licensing is compatible and we don't infringe anything.
Therefore such actions are not that straightforward, being more than
just technical side and getting something compiled.
I thought you got the rpms built by having the rabbitmq and jsoc-c
libraries built separately and made as constraints for building
kamailio-kazoo package. Is it right?
There are many modules not built for old distros (like redis, mongodb,
cassandra), we cannot embed all these libraries, it's going to get too
complex and messy. The solution I still find the best is to build these
libs as separate packages and offer them via custom (our) repos. Iirc,
we built hiredis lib for a while, not sure it is still the case.
However, we cannot get it pushed to old distros and again, embedding
everything can result in getting all kamailio removed, not following the
standard linux procedure/structure with libs.
Cheers,
Daniel
cheers
________________________________________
From: sr-dev-bounces(a)lists.sip-router.org [sr-dev-bounces(a)lists.sip-router.org] on behalf
of Daniel-Constantin Mierla [miconda(a)gmail.com]
Sent: Monday, November 10, 2014 5:33 AM
To: Kamailio (SER) - Development Mailing List
Subject: Re: [sr-dev] git:4.2: kazoo : remove dependencies
I don't feel comfortable about this commit.
If it was a backport, it has to be done with 'git cherry-pick -x'
The it looks like it messes up with the build system we have in the
stable branch, adding shared objects in different location than internal
libs and modules.
Could you revert the commit in branch 4.2 and explain how all these
imported libraries are built, installed and planned to be managed. Maybe
there are better solutions or other people have solutions for a way that
can be reused by other modules.
I don't like importing external libraries in our source code unless it
is a clear reason for it and everyone agrees with it.
Also, remember that 4.2 is stable, pushing radical changes without
discussing on sr-dev is strongly not recommended. It can break existing
installations that are maintained from git. On git master, you have the
freedom to play as you think is better, but not backporting immediately
to any stable branch.
Cheers,
Daniel
On 10/11/14 14:26, Luis Azedo wrote:
Module: sip-router
Branch: 4.2
Commit: 1630ec25958bda98a98864cbef57000dab8f2aeb
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1630ec2…
Author: Luis Azedo <luis(a)2600hz.com>
Committer: Luis Azedo <luis(a)2600hz.com>
Date: Mon Nov 10 13:25:30 2014 +0000
kazoo : remove dependencies
---
modules/kazoo/Makefile | 27 +-
modules/kazoo/README | 4 +-
modules/kazoo/deps/Makefile | 18 +
modules/kazoo/deps/amqp.h | 2352 +++++++++++++++++++++++++++++
modules/kazoo/deps/amqp_api.c | 340 +++++
modules/kazoo/deps/amqp_connection.c | 535 +++++++
modules/kazoo/deps/amqp_consumer.c | 308 ++++
modules/kazoo/deps/amqp_framing.c | 2102 ++++++++++++++++++++++++++
modules/kazoo/deps/amqp_framing.h | 640 ++++++++
modules/kazoo/deps/amqp_hostcheck.c | 201 +++
modules/kazoo/deps/amqp_hostcheck.h | 36 +
modules/kazoo/deps/amqp_mem.c | 252 +++
modules/kazoo/deps/amqp_openssl.c | 626 ++++++++
modules/kazoo/deps/amqp_private.h | 363 +++++
modules/kazoo/deps/amqp_socket.c | 1388 +++++++++++++++++
modules/kazoo/deps/amqp_socket.h | 195 +++
modules/kazoo/deps/amqp_ssl_socket.h | 168 ++
modules/kazoo/deps/amqp_table.c | 614 ++++++++
modules/kazoo/deps/amqp_tcp_socket.c | 303 ++++
modules/kazoo/deps/amqp_tcp_socket.h | 73 +
modules/kazoo/deps/amqp_timer.c | 140 ++
modules/kazoo/deps/amqp_timer.h | 67 +
modules/kazoo/deps/amqp_url.c | 218 +++
modules/kazoo/deps/arraylist.c | 101 ++
modules/kazoo/deps/arraylist.h | 56 +
modules/kazoo/deps/bits.h | 28 +
modules/kazoo/deps/config.h | 209 +++
modules/kazoo/deps/debug.c | 83 +
modules/kazoo/deps/debug.h | 71 +
modules/kazoo/deps/json.h | 34 +
modules/kazoo/deps/json_c_version.c | 20 +
modules/kazoo/deps/json_c_version.h | 22 +
modules/kazoo/deps/json_config.h | 4 +
modules/kazoo/deps/json_inttypes.h | 28 +
modules/kazoo/deps/json_object.c | 855 +++++++++++
modules/kazoo/deps/json_object.h | 612 ++++++++
modules/kazoo/deps/json_object_iterator.c | 168 ++
modules/kazoo/deps/json_object_iterator.h | 239 +++
modules/kazoo/deps/json_object_private.h | 47 +
modules/kazoo/deps/json_tokener.c | 890 +++++++++++
modules/kazoo/deps/json_tokener.h | 208 +++
modules/kazoo/deps/json_util.c | 300 ++++
modules/kazoo/deps/json_util.h | 41 +
modules/kazoo/deps/libjson.c | 26 +
modules/kazoo/deps/linkhash.c | 602 ++++++++
modules/kazoo/deps/linkhash.h | 292 ++++
modules/kazoo/deps/math_compat.h | 38 +
modules/kazoo/deps/printbuf.c | 192 +++
modules/kazoo/deps/printbuf.h | 77 +
modules/kazoo/deps/random_seed.c | 237 +++
modules/kazoo/deps/random_seed.h | 25 +
modules/kazoo/deps/threads.h | 29 +
modules/kazoo/doc/kazoo_admin.xml | 12 +-
modules/kazoo/kazoo.c | 15 +
modules/kazoo/kz_amqp.c | 150 ++-
modules/kazoo/kz_amqp.h | 6 +
modules/kazoo/kz_pua.c | 3 +-
57 files changed, 16644 insertions(+), 46 deletions(-)
Diff:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=163…
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin -
http://www.asipto.com
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev --
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin -
http://www.asipto.com
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin -
http://www.asipto.com