[OpenSIPS-Users] 2.2.2 packaging

[Răzvan Crainea]

Hello, Nathan!

You have my answer inline.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 01/07/2017 11:10 AM, Nathan Ward wrote:
> Hi,
>
> I am running OpenSIPS 2.2.2 from RPMs from the opensips.org yum server.
>
> I am trying to find out where the SPEC files to generate the CentOS (/el7) RPMs are. I don’t seem to be able to find these in GitHub. Can someone help with this?
Nick (CC'ed) is maintaining the SPECS for the CentOS RPMs, but I am not 
sure all changes are integrated in the RPM files. But AFAIK, they are 
based on the public specs here:
  https://github.com/OpenSIPS/opensips/blob/2.2/packaging/rpm/opensips.spec.CentOS
>
>
> I am hoping to submit a PR to move the ‘opensips’ binary to /usr/libexec, rather than a common $PATH location. We have had a problem where this binary was mistakenly run, rather than opensipsctl. Typically, daemon binaries that do not generally get run by users should be in /usr/libexec so that they are only very intentionally executed. This should probably go in to at the very least a minor version change as it may break some people’s custom init scripts etc.
I am not sure I fully agree with this. /usr/libexec contain binaries 
that should never be run as stand-alone. But that is not OpenSIPS' case, 
where you can easily start it in debug mode or smth like that. For 
example, a similar daemon is sshd, which is located in /usr/sbin/sshd. 
However, internally triggered binaries, such as sftp-server are located 
in /usr/libexec/openssh/sftp-server. This exec should never be executed 
outside sshd.
>
>
> On my search, I note change 9e406b2b3acfd61b39ba9679f0a599b95f56f5c2 under the 2.2.2 tag, which appears to be done with something like:
> sed ’s/2.2.1/2.2.2/‘
>
> Note the matches where . is ‘any’ not a literal period, so there are a lot of dates that get messed up:
>   -* Mon Oct 12.2.19 Bogdan-Andrei Iancu <bogdan at opensips.org>
>   +* Mon Oct 12.2.29 Bogdan-Andrei Iancu <bogdan at opensips.org>
You are right, this is a bug in my changelog update script. I will 
update it now.

Best regards,
Răzvan