PMS documents "usev" as follows: "The same as use, but also prints the flag name if it is enabled." Portage behaviour for "usev !foo" is different (and makes more sense): - with foo enabled, it is silent - with foo disabled, it prints "!foo"
Created attachment 191997 [details, diff] Proposed fix
Can we classify Portage's behaviour here as 'clearly silly' and mark it as undefined behaviour in this EAPI and get Portage to fix it in the next?
(In reply to comment #2) > Can we classify Portage's behaviour here as 'clearly silly' and mark it as > undefined behaviour in this EAPI and get Portage to fix it in the next? No.
Fairly sure we can, since it is clearly silly and nothing's using it anyway.
(In reply to comment #4) > Fairly sure we can, since it is clearly silly and nothing's using it anyway. Please explain, what is silly about Portage's behaviour here? Pkgcore does the same, btw. You want "usev !foo" to echo "foo" with USE=foo and be silent with USE=-foo, as current wording in PMS suggests? If Paludis behaves different, then Paludis is broken and should be fixed.
The ! is an operator, not part of the flag name. The ! doesn't end up getting displayed for other use functions that accept it, which strongly suggests it's just an oversight.
Here is a table, to make things clear (haven't really tested with Pkgcore and Paludis, only looked at their source code): +---------+-----------+-----------+-----------+-----------+ | | usev foo | usev foo | usev !foo | usev !foo | | | USE=-foo | USE=foo | USE=-foo | USE=foo | +---------+-----------+-----------+-----------+-----------+ | PMS | (nothing) | foo | (nothing) | foo | +---------+-----------+-----------+-----------+-----------+ | Portage | (nothing) | foo | !foo | (nothing) | +---------+-----------+-----------+-----------+-----------+ | Pkgcore | (nothing) | foo | !foo | (nothing) | +---------+-----------+-----------+-----------+-----------+ | Paludis | (nothing) | foo | foo | (nothing) | +---------+-----------+-----------+-----------+-----------+ Looks like all three package managers must be changed, if we follow your suggestion.
We need to change the 'it' in PMS, at least... It's highly unclear whether the 'it' refers to the flag name, as you read it, or the 'useq', which is what it's supposed to say...
(In reply to comment #8) > We need to change the 'it' in PMS, at least... That's what I'm saying. ;-) > It's highly unclear whether the 'it' refers to the flag name, as you read it, > or the 'useq', which is what it's supposed to say... The word "enabled" seems to indicate that the flag itself is meant (but I'm not a native english speaker). Also the behaviour is not completely undefined, so we do better than this. All package managers print something iff the return value is true. "The same as use, but prints its argument or the flag name (implementation dependent) if the return value is true."
Mm, we probably shouldn't be using the term 'true' to refer to a zero exit status. I'd guess "if the condition is met" is clearest. Still think we should standardise this to never outputting the ! in EAPI 4.
I've scanned the current Portage tree: Nobody is using usev with a negated argument. In old snapshots I've found one example, but concrete output didn't matter for it. So can we please keep any additional clutter (like needless EAPI differences) out of the specification? The important thing is that something should be printed for true (0) and nothing for false (1). "The same as use, but prints its argument or the flag name (implementation dependent) if and only if the condition is met." (In reply to comment #10) > Still think we should standardise this to never outputting the ! in EAPI 4. We can standardise it when someone comes up with a real usage case for printing either "flag" or "!flag".
The only plausible use case I can come up for for !flag is for a --disable-things= or --without-things= style argument call, which definitely doesn't want the !. I can't think of any possible case for showing the !, since it's not even something you could tell users to do.
Yeah, I'm not going to defend the exclamation mark ... only trying to keep the spec free from needless case distinctions. Bug 30360 comment #2 shows that the original intention was to print the flag without the exclamation mark. This was changed (accidentally?) between portage-2.0.50_pre20 and _pre22: <http://sources.gentoo.org/viewcvs.py/gentoo-src/portage/bin/ebuild.sh?r1=1.153&r2=1.154>
Ok, so back to comment #2 with a slight variation: can we classify this as a Portage bug and clarify the spec?
(In reply to comment #14) > Ok, so back to comment #2 with a slight variation: can we classify this as a > Portage bug and clarify the spec? O.K. with me, if you don't make it an EAPI issue. @zmedico: Any objections? The devmanual has a very compact formulation, BTW: "As use, echoes flagname upon success."
<ulm> zmedico: bug 270658, is it o.k. if we clarify the PMS spec for "usev" to say "echoes flagname upon success"? <zmedico> ulm: yeah, sounds fine <ulm> zmedico: you are aware that this is not current portage behaviour? <ulm> so in usev the 'echo "${1}"' should be changed to 'echo "${1#!}"' <zmedico> is that going to break anything? <zmedico> we need to check that first <ulm> zmedico: no, it's not used in the tree <zmedico> cool, it's fine by me then
Created attachment 192366 [details, diff] New proposed fix
I still don't like 'success'. We don't use it anywhere else. How about 'condition is met'?
> How about 'condition is met'? Fine with me.
Ok, applied with that tweak, thanks.
(In reply to comment #16) > <ulm> so in usev the 'echo "${1}"' should be changed to 'echo "${1#!}"' This is in svn r13628.
This is fixed in sys-apps/portage-2.2_rc34.
