From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Enge Subject: Re: patches question Date: Thu, 23 Jun 2016 13:09:43 +0200 Message-ID: <20160623110943.GA748@solar> References: <20160623104107.GA2505@shadowwalker> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58842) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bG2W8-0004Yp-Ks for guix-devel@gnu.org; Thu, 23 Jun 2016 07:09:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bG2W4-0005WR-Hs for guix-devel@gnu.org; Thu, 23 Jun 2016 07:09:52 -0400 Received: from mailrelay2.public.one.com ([91.198.169.125]:17277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bG2W4-0005WH-53 for guix-devel@gnu.org; Thu, 23 Jun 2016 07:09:48 -0400 Content-Disposition: inline In-Reply-To: <20160623104107.GA2505@shadowwalker> 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: guix-devel@gnu.org Hello, On Thu, Jun 23, 2016 at 10:41:08AM +0000, ng0 wrote: > After the last reply to my netcat-openbsd, I am > uncertain about the kind of patches which can > be included by policy. my opinion is: as few patches as possible, given that we need to maintain them with very little peoplepower, and that we do not intend to substitute ourselves to upstream. Also, if possible, things should be reported upstream so that we can take patches out again. Another reason to do so is that packages should essentially behave in the same way as the same software compiled by hand. Recall also cases of security problems introduced into other distributions by non-upstream adding patches to cryto software they did not completely understand. > For firefox, I would start to include what fixes > buildprocess for us and fixes bugs (including > features) upstream has not bothered to close yet > or in general. Particularities of our build process may clearly make patches necessary (although I often prefer to treat them more generically in a build phase, using "substitute*", for instance, which may be more robust across package updates). After that, I would consider mainly security fixes and maybe important functional fixes made by upstream that are not yet in a release. Clearly features that upstream does not bother to implement are not acceptable for patches, as they will have to be maintained and adapted indefinitely. > For firefox, bundled libraries and applications > can be patched away (system graphite+harfbuzz), Unbundling and removal of non-free parts are also possible cases, although most of the time this is done by a call to "delete-file-recursively" in a snippet. > That is what the netcat-openbsd-* files of debian > are about I assume (but I have not asked debian > yet). I do not know about this particular software, but while Debian is a good source for copyright info and patch material, they definitely are not our lead as to the decision of whether to include patches: If you divide our number of packages by the number of regular contributors, you will end up with a few hundred packages per person. I think Debian has no particular policy as to which patches are acceptable, and that this is mainly up to the package maintainer. In our case, since we do not have designated maintainers, every additional patch is an additional burden on the person trying to update or more generally work on a package later. As a bad example of a Debian patch, I have encountered one that corrected an English typo in a comment (!) in the C code of a package. Andreas