Re: [Patch 1/10] Add pjproject.

[Ricardo Wurmus]

Hi Lukas,

> Sorry for the delay!

Likewise! :)

> Ricardo Wurmus <address@hidden> 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?

Thanks for the explanations!

I think it would be better to change the name to “pjproject-sfl” as
well.  Not sure about what to do about the version number, because it
clearly isn’t the same as upstream “pjproject”.

I still think that the definition of “sfl-patches” is particularly
ugly.  Considering that you actually get the very same sources for the
“libring” package and “pjproject-sfl” is only used by “libring” (please
correct me if I’m wrong), I think it’s not pretty to take the sources
and delete everything but the patches.  In this case I think it may be
better to merge the definitions of “pjproject” and “libring”.

It seems to me that much of what is now “pjproject” (e.g. the snippet to
leave only the patches, the extra build phases, etc) would no longer be
needed when building “pjproject” as part of “libring”.  Merging the two
might make this all a lot clearer.

What do you think?

~~ Ricardo


PS: for future reference, this

(lambda (file)
 (if (or (string=? file ".")
         (string=? file ".."))
 #f
 #t))

could more concisely be written as

(cute (not (or (string=? <> ".")
               (string=? <> ".."))))