< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index |
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 library. 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. Regards, Daniel
Attachment:
2018-09-reSIProcate-dependency-hierarchy.tif
Description: TIFF image