From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: [Patch 1/10] Add pjproject. Date: Sat, 05 Nov 2016 23:25:27 +0100 Message-ID: <87zild8syw.fsf@elephly.net> References: <87mvjc1quq.fsf@openmailbox.org> <87inu01qsj.fsf@openmailbox.org> <87shswmj48.fsf@elephly.net> <87oa3j870k.fsf@openmailbox.org> <87bmzg8xe1.fsf@elephly.net> <87r387tb7l.fsf@openmailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c39PB-00089z-9r for guix-devel@gnu.org; Sat, 05 Nov 2016 18:25:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c39P8-0000vP-57 for guix-devel@gnu.org; Sat, 05 Nov 2016 18:25:41 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:21418) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c39P7-0000sU-RQ for guix-devel@gnu.org; Sat, 05 Nov 2016 18:25:38 -0400 In-reply-to: <87r387tb7l.fsf@openmailbox.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Lukas Gradl Cc: guix-devel@gnu.org Hi Lukas, > Sorry for the delay! Likewise! :) > Ricardo Wurmus 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=? <> ".."))))