Hi Ricardo,

Sorry for the delay!

Ricardo Wurmus <rekado@elephly.net> writes:
>> My idea here is the following:  The source tree downloaded here contains
>> the complete source for libring, which includes the patches to
>> pjproject.  In this snippet I try to get rid of all the other libring
>> files that are not needed and only keep the patches to pjproject.  Then
>> I try to make the directory tree that contains these patches as shallow
>> as possible.  I remember I had some problems with copying them to "."
>> but trying again now it works.  I attached an updated patch that does
>> this.
>
> Is there no release that includes these patches?  Why do we have to
> apply them ourselves?  In Guix we try to avoid patching upstream sources
> with functional patches (as opposed to patches that fix problems with
> building the software on Guix), as this is really upstream’s work.

There is no release that I know of that contains these patches.  The
Ring project ships a Makefile in the 'contrib' directory of the
'libring' source tree that downloads the upstream Pjproject source
and applies these very same patches to it.  It then continues to build a
bundled version of pjproject + patches.

> Is this really pjproject version 2.4 when we apply a massive patch set
> like that?

It is not.  It is a fork of pjproject that introduces several functional
changes, the most notable one being the use of GnuTLS instead of
OpenSSL.  I suspect the Ring project's motivation for doing this are at
least in part legal issues as the OpenSSL license seems to be
incompatible with the GPL according to
"http://www.gnu.org/licenses/license-list.html".  I don't know if there
are technical benefits of using one over the other.

I tried to denote the fact that this is a fork of pjproject by naming
the variable 'pjproject-sfl' instead of just 'pjproject'.  I could go
further and make it local to the definition of libring or change the
name of the package?


Thank you!

Best,
Lukas