From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1REZVo-00017R-Ly for garchives@archives.gentoo.org; Fri, 14 Oct 2011 04:36:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9228821C05D; Fri, 14 Oct 2011 04:36:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id AF4C621C023 for ; Fri, 14 Oct 2011 04:36:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3EA7D1B4016 for ; Fri, 14 Oct 2011 04:36:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 required=5.5 tests=[AWL=-0.496, BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_NUMERIC_HELO=1.164, RP_MATCHES_RCVD=-0.504] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dquYRJUSbOin for ; Fri, 14 Oct 2011 04:35:53 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id B9DB31B4013 for ; Fri, 14 Oct 2011 04:35:52 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1REZUp-0005x0-Nk for gentoo-dev@gentoo.org; Fri, 14 Oct 2011 06:35:47 +0200 Received: from 109.176.230.222 ([109.176.230.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Oct 2011 06:35:47 +0200 Received: from slong by 109.176.230.222 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Oct 2011 06:35:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in app-admin/chrpath: ChangeLog chrpath-0.13-r2.ebuild Followup-To: gmane.linux.gentoo.devel Date: Fri, 14 Oct 2011 05:39:30 +0100 Organization: Friendly-Coders Message-ID: References: <20111011164918.2103A2004B@flycatcher.gentoo.org> <4E9475E1.30708@gentoo.org> <20111011170555.GV704@gentoo.org> <4E948484.1000509@gentoo.org> <20111011181358.GW704@gentoo.org> <4E948C2E.2000706@gentoo.org> <20111011214847.0d03c511@pomiocik.lan> <4E95E83D.8060906@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.230.222 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: aa96a1ef05783160d6e84ac95da7faef Samuli Suominen wrote: > On 10/12/2011 06:30 AM, Steven J Long wrote: >> Micha=C5=82 G=C3=B3rny wrote: >>> I don't think that passing multiple files to epatch actually improves >>> readability. Simple example: >>> >>> # bug #123456, foo, bar >>> epatch "${FILESDIR}"/${P}-foo.patch >>> # bug #234567, baz bazinga blah blah >>> epatch "${FILESDIR}"/${P}-baz.patch >>> >>> With multiple arguments, you can't put comments in the middle. >>> >> ++ It's also a lot easier to remove the single patches when they're no >> longer needed. >=20 > Removing an 'epatch foo' line is easier than 'foo \' ? You are kidding= , > right? > No; in general, most editors make it really simple to delete a line. Not=20 having to worry about line-continuation is just another routine memo that= =20 doesn't have to be kept in mind*, and I'd argue that it's useful to reade= rs=20 of the ebuild, to have the bug # in the ebuild. * All right, not a *lot* easier, just a bit ;-) >> In the context of configuring, building and installing a >> package, the extra overhead is miniscule, whereas the above is *much* >> easier to maintain. >=20 > Based on what argument? Based on it being easier to edit, and easier to look up the bug straight=20 from the ebuild, should someone working with an ebuild choose (or need) t= o=20 do so. I guess I'm arguing for Mike's style within the ebuild (tho that=20 PATCHES array looks nice and allows bug # comments.) Again, perhaps '*much*' went a bit far; sorry for that. > Having the comments inside the patch allows everyone, including > _upstreams_ straight up see what's it for and link to the bug it's > coming from. Where as keeping them in ebuilds makes it Gentoo specific, > which is not what we are about. Having a bug # in the ebuild doesn't excuse anyone from having correct=20 comments in the patch; they're orthogonal imo. Personally I think you sho= uld=20 do both; bug # in ebuild* so a user can quickly look up what's happening,= =20 and both full bug URL, and a fuller explanation in the patch. Bug # in=20 ebuild is also useful when you get an ebuild from someone and no patches = in=20 files/ as it's effectively a fragment. You can argue it's redundant; I se= e=20 it as equivalent to a doubly-linked list: you don't _need_ both links to=20 function, but it makes things easier. In any event you're the maintainer; but this was a discussion about style= ,=20 well "readability" at least, and I think it's better practice to have bug= #=20 in ebuild. Regards, igli. ---- * After all, you only add the bug id once, when you're adding the patch a= nd=20 are well aware of what bug/s you're working on; it's not an ongoing burde= n. --=20 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)