I'm not sure what exactly happened here, so adding x86@ to verify since they made the commit. if [[ ${PV} == *9999* ]] ; then KEYWORDS="x86" http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/ktorrent/ktorrent-3.3.4.ebuild?r1=1.3&r2=1.4
if [[ ${PV} == *9999* ]] ; then - KEYWORDS="x86" + KEYWORDS="amd64 x86" http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/ktorrent/ktorrent-3.3.4.ebuild?r1=1.4&r2=1.5
I have dropped keywords from *9999* again. Seems that ekeyword changes keywords in both places (I can reproduce it always) Thanks Samuli for CCing us
Confirmed, I was also using ekeyword. :( Good catch.
An alternative solution would be to disallow more than one occurrence of KEYWORDS in an ebuild (via a mandatory repoman check for example).
(In reply to comment #4) > An alternative solution would be to disallow more than one occurrence of > KEYWORDS in an ebuild (via a mandatory repoman check for example). > It's perfectly legal to have second set of KEYWORDS behind if -statement and ${PV} because it doesn't break metadata cache. That would also make maintaining -9999 (scm ebuilds) more cumbersome[1] [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-video/ffmpeg/ffmpeg-9999-r1.ebuild?r1=1.36&r2=1.37 "Make KEYWORDS depend on PV to make it easier to bump." The only option here is to either fix ekeyword or delete it entirely.
So in my opinion we have two options: 1) check for four nines (9999) in the version string (filename) and don't touch KEYWORD variables at all in case it matches. But that means that live ebuilds without any 9999 would be touched anyway. 2) Skip the empty KEYWORDS variable in case of more than two KEYWORD variables has been detected (Thanks to Sebastian Pipping for pointing that out)
(In reply to comment #6) > So in my opinion we have two options: > 1) check for four nines (9999) in the version string (filename) and don't touch > KEYWORD variables at all in case it matches. But that means that live ebuilds > without any 9999 would be touched anyway. Please note that in this case the file did not match -9999 pattern. Each ebuild had the conditional logic for this -9999 version. > 2) Skip the empty KEYWORDS variable in case of more than two KEYWORD variables > has been detected (Thanks to Sebastian Pipping for pointing that out) Please also consider: 3) Refuse to do anything if there is more than one KEYWORDS line in the ebuild. (I'd prefer this) 4) Refuse to touch KEYWORDS line that is indented (which suggest a conditional statement). Also, it would be nice to print all changes to the file. It seems ekeyword only prints one. Could it save the original version of the file, and print the out of "diff -u original changed"? We're unlikely to prevent all possible gotchas, but printing the diff will make us detect the mistake quickly. By the way, since this bug got reported, I always run cvs diff after running ekeyword. Implementing the change above would save me a bunch of keystrokes and cvs server roundtrips. :)
(In reply to comment #7) > (In reply to comment #6) > > So in my opinion we have two options: > > 1) check for four nines (9999) in the version string (filename) and don't touch > > KEYWORD variables at all in case it matches. But that means that live ebuilds > > without any 9999 would be touched anyway. > > Please note that in this case the file did not match -9999 pattern. Each ebuild > had the conditional logic for this -9999 version. > > > 2) Skip the empty KEYWORDS variable in case of more than two KEYWORD variables > > has been detected (Thanks to Sebastian Pipping for pointing that out) And don't go from <none> to <stable> directly. > Please also consider: > > 3) Refuse to do anything if there is more than one KEYWORDS line in the ebuild. > (I'd prefer this) Maybe make behaviour controlled by a switch for automated scripts.
fauli, you just committed the change to uzbl: $ grep KEY uzbl-2010.04.03.ebuild KEYWORDS="x86" KEYWORDS="~amd64 x86" please, everyone stop using ekeyword until this is solved :-(
(In reply to comment #9) > fauli, you just committed the change to uzbl: > > $ grep KEY uzbl-2010.04.03.ebuild > KEYWORDS="x86" > KEYWORDS="~amd64 x86" > > please, everyone stop using ekeyword until this is solved :-( I rely on scripts for proper operation, so I will check more thoroughly the output, but going without ekeyword is not an option.
Please test gentoolkit-dev-9999.
(In reply to comment #11) > Please test gentoolkit-dev-9999. Works as expected. Thanks a lot.
This has been fixed in gentoolkit-dev-0.2.7.
According to pms, keywords is optional, so it is completely legit to leave keywords out f the live portion of an ebuild like this: if [[ ${PV} = "9999" ]]; then ... else # for releases KEYWORDS="~amd64" fi Hopefully the fix in this bug accommodates that.
