< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] resiprocate packaging

On 21/09/18 19:01, Ingo Feinerer wrote:
> Hi,
> I am in the process of preparing a OpenBSD package/port of various
> resiprocate components. In this context I am wondering what is the
> best/recommended way to package individual components of resiprocate.
> The Debian packages are quite fine grained; I think this is not
> necessary for the typical OpenBSD user. So:
> The configure script lists (configure --help) several "Optional Packages":
> --with-repro            Build repro, requires CAJUN and bdb
> --with-rend             Build rend
> --with-recon            Build recon, links against sipX
> and so on. These make logical additions which could be packaged; that is
> the way I handle repro (basically all the file additions generated by
> --with-repro and --enable-repro-plugins).
> But I wonder what is actually the "base" package. It seems that reTurn
> is always built. Is it correct to assume that the minimal installation
> should always include the reTurn TURN/STUN component?

reTurn (server) is optional.  The reTurn client code is needed to build
some other libraries like recon.

It is quite possible for somebody to run repro on one host and reTurn on
a different host, or only use one and never use the other.

The only thing that I believe to be a common dependency for everything
else is the rutil library code.  There is no rutil executable, only a

The reTurnClient code and the reTurnServer executable share some class
files.  Those class files should be in a reTurnCommon shared library, I
never got around to tidying that up but it isn't hard.

I attach a diagram giving an overview of the dependency hierarchy.  I
left out the dependencies for unit tests, the apps/* directory and the
third party libs.  The components with double circles are executables,
the single circles are libraries.

The directory hierarchy only roughly approximates the dependency
hierarchy, maybe some directories could be rearranged.  For example,
repro, reTurnServer and MOHParkServer could go under apps.

Thanks for your interest in packaging, please feel free to ask questions
and look for clues in the Debian package files.  I've also done Fedora
packaging, Android build and some Solaris packaging and the artefacts
for those packages might also provide some hints for further packaging
efforts too.



Attachment: 2018-09-reSIProcate-dependency-hierarchy.tif
Description: TIFF image