From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 17109138247 for ; Tue, 14 Jan 2014 04:59:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CBAB3E0B98; Tue, 14 Jan 2014 04:59:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 965ABE0B97 for ; Tue, 14 Jan 2014 04:59:07 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id C726F33F622; Tue, 14 Jan 2014 04:59:06 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: Tom Wijsman Subject: Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 Date: Mon, 13 Jan 2014 23:59:11 -0500 User-Agent: KMail/1.13.7 (Linux/3.12.1; KDE/4.6.5; x86_64; ; ) Cc: gentoo-portage-dev@lists.gentoo.org, creffett@gentoo.org References: <1389658110-14528-1-git-send-email-creffett@gentoo.org> <201401131950.45341.vapier@gentoo.org> <20140114042301.4b7075a7@TOMWIJ-GENTOO> In-Reply-To: <20140114042301.4b7075a7@TOMWIJ-GENTOO> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5342185.zVSFTg6SQX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201401132359.12579.vapier@gentoo.org> X-Archives-Salt: b02f9459-cf15-4b4a-acc6-face75c40c9e X-Archives-Hash: fdcba61a0edd6924750c6517bc06cbbe --nextPart5342185.zVSFTg6SQX Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday 13 January 2014 22:23:01 Tom Wijsman wrote: > On Mon, 13 Jan 2014 19:50:44 -0500 Mike Frysinger wrote: > > On Monday 13 January 2014 19:08:30 creffett@gentoo.org wrote: > > > From: Chris Reffett > > > Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if > > > src_prepare/src_configure are used in EAPI 0/1 >=20 > Well, I was planning to cover these bugs; seems we really need to > organize with regards to avoiding double work, as two others have got > the same happen to them. Let's synchronize it. we have a bugzilla workflow doc posted which we'll merge once git is back u= p. =20 please do not reassign portage bugs to yourself. instead, set the status t= o=20 INPROGRESS. > While vapier's case could be considered as valid; I think we should > consider that as a bad practice, as one could just as well put the if > inside a phase which is the much more common practice. certainly, but we need to notify the dev community first > As a note, my WIP work is at the next url; there you can see the bug > numbers I've been working on (still need to revise them, properly > document the added check errors [eg. in `man repoman`] and so on). >=20 > https://github.com/TomWij/gentoo-portage-next/branches we probably should just use dev branches in the main repo, at least for peo= ple=20 who have write access to the repo dev/$USERNAME/ > > you might want to set ~/.gitconfig to have your name/email so that > > git sendemail uses the right info in the actual e-mail From: field >=20 > Then what is the From: field that it puts separately into the e-mail > itself? the Author field of the git commit > Seems quite odd for these to differ; or, is the latter an > attempt to mark the author? Then why does the e-mail From: field need > to be correct? Afaik it would only use one of both, so only one of both > needs to be correct. But that would make the actual question: Which one? if they differ, git will post the From: as the first line of the body so th= at=20 `git am` can do the right thing. if they're the same, then git omits it. they don't *need* to be the same for patches to be merged correctly, but th= ey=20 should be the same to cut down on extraneous noise. the focus is the commi= t=20 message/code, not other random junk that takes 3 seconds to fix with a=20 configuration tweak. > > i'd suggest merging the regex a little: > > r'^\ssrc_(configure|prepare)\s*\(\)' >=20 > Note that the * behind the first \s was lost; so, with the redundant ^ > removed and the * put back it would be: yes, typo when i hand wrote it > r'\s*src_(configure|prepare)\s*\(\)' >=20 > You can then proceed further and move the re outside: the idea was to walk a balance between simplicity and maintainability. imo= ,=20 the fixed version above is the best. > > the regex is naive and can match valid ebuilds. consider ones that > > handle $EAPI itself and will call the right funcs as necessary. >=20 > From a QA point of view it seems more preferable to move away from old > EAPIs, than to conditionally support them. The common case is that > ebuilds move from older to newer EAPI and thus would get these > functions as they get to a newer EAPI. >=20 > Is there an actual case for downgrading back to an older EAPI? >=20 > If not, conditional code that checks $EAPI has no purpose. and yet it exists today. as long as portage supports an EAPI, i see no rea= son=20 to omit useful checks like this. =2Dmike --nextPart5342185.zVSFTg6SQX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJS1MQgAAoJEEFjO5/oN/WBkIUQAJRpdcVbliRlPOoOP9SV0n9P I6yfzv+7WbrWA3eaiql3hdcGA8+kH08uad7pyz0ltRH/TF/sqGIoQiZHGBN7CkOH 8hp5qVdTIiPyeGCr3YOXvXL5cP4dWJ/RGlkmEKwmfee+Wygq1fEy/oqGsYTDu25T x+4OZxdq/9nfgoEuHSdrie+sAfwDVYQMWSLaL1oMBGU/BlfhXlLrFyzWk7y7zHfg Yw9KlSTCv8e1U6Ji5lMl7ZvfizfFAp/SYrl0DUKPn39HVkUI3aDfYW0f/wI2u6Zo kGKRgQI7dt5ldZuZlrOohPoQTGgz4qT1f/w+t1dp7J/qKq1BnDeddggBh6fYV9JF cSdmglVDc8c0TCU+AwedDOcVSOCj0eSGsmOlZoMFMB1AaXEnpJm9gHj5PxU806Ql lIWBf/9Oi7DgzdMuAIK6iDwaY/yS1ozm8xCN6BkkpLKwt51zf5XUkd0kq5K61P+g 2VJwSec8UrgnjaNtFMTxqi0kg8EBW21poWFjcvfFw2zs3Vdso/7J5bYLdH3dSvxK c5NE4CCjc44ekIZ8uplRM5DiBG/tjCO4yBIg7FmJpnpoWWWOZJ0trnjCX6/uOleL 1Xe5pDqlNPOZyeKExf7F2rFUdln8a6k/KdYu5vlg+Gx7XAcdDyJVE96n4xaC4Gmu E8HZOzsoBNOnt2dwfTa6 =i1xg -----END PGP SIGNATURE----- --nextPart5342185.zVSFTg6SQX--