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 [email protected] wrote: > > > From: Chris Reffett <[email protected]> > > > Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if > > > src_prepare/src_configure are used in EAPI 0/1 > > 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 up. please do not reassign portage bugs to yourself. instead, set the status to 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). > > https://github.com/TomWij/gentoo-portage-next/branches we probably should just use dev branches in the main repo, at least for people who have write access to the repo dev/$USERNAME/<whatever you want> > > 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 > > 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 that `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 they should be the same to cut down on extraneous noise. the focus is the commit message/code, not other random junk that takes 3 seconds to fix with a configuration tweak. > > i'd suggest merging the regex a little: > > r'^\ssrc_(configure|prepare)\s*\(\)' > > 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*\(\)' > > You can then proceed further and move the re outside: the idea was to walk a balance between simplicity and maintainability. imo, 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. > > 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. > > Is there an actual case for downgrading back to an older EAPI? > > 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 reason to omit useful checks like this. -mike
signature.asc
Description: This is a digitally signed message part.
