From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: patches question Date: Thu, 23 Jun 2016 11:30:35 +0000 Message-ID: <20160623113034.GA4667@shadowwalker> References: <20160623104107.GA2505@shadowwalker> <20160623110943.GA748@solar> 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]:36658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bG2qP-0001ID-HA for guix-devel@gnu.org; Thu, 23 Jun 2016 07:30:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bG2qK-0002sJ-1C for guix-devel@gnu.org; Thu, 23 Jun 2016 07:30:48 -0400 Received: from 93-95-228-168.1984.is ([93.95.228.168]:50177 helo=beleriand.n0.is) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bG2qJ-0002sC-Ds for guix-devel@gnu.org; Thu, 23 Jun 2016 07:30:43 -0400 Received: by beleriand.n0.is (OpenSMTPD) with ESMTPSA id c4d95bf5 TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Thu, 23 Jun 2016 11:30:38 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20160623110943.GA748@solar> 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 On 2016-06-23(01:09:43PM+0200), Andreas Enge wrote: > 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. Okay, sounds logical and reasonable. I wanted to ask Debian about the netcat-openbsd case and why certain features are added/fixed. > > 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. The length of the package definition in this case could be smaller. With comments it's at 300 lines now. Some temporary patches to open bugs would increase this length. That's my only motivation for the patches directory, length of code. If it does not matter, I will do it in the packages themselves as long as possible even for non-trivial fixes. > > 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 > > In the case of netcat-openbsd, Debian is the Linux upstream, maintaining the port of netcat from OpenBSD. The patches have not seen an update since 2012 and are still functional. I can understand that we don't want to maintain more patches than necessary, so in the case of netcat-openbsd I'll contact Debian, as mentioned in the thread of the patch, to ask about a merge of their patches into their maintained port. If the reply is negative, I'll look at the patches and only take what's really necessary. -- ♥Ⓐ ng0 For non-prism friendly talk find me on psyced.org / loupsycedyglgamf.onion