Summary: | [Future EAPI] Zero-or-one-of operator for REQUIRED_USE | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Ulrich Müller <ulm> |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | dev-portage, esigra, ferringb, mgorny |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | in-eapi-5 | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 |
Description
Ulrich Müller
2011-02-09 10:16:29 UTC
(In reply to comment #0) > Of course there are several ways to express it with the existing operators, but > already for three flags it's becoming clumsy and difficult to read: > ^^ ( foo bar baz ( !foo !bar !baz ) ) Well, that could be written as: ^^ ( foo bar baz ( !foo ) ) In fact, going this way we could even go to: ^^ ( foo bar baz ( ) ) but this doesn't work in portage. Not sure if it could be considered as a bug, portage just drops empty group. (In reply to comment #1) > (In reply to comment #0) > > Of course there are several ways to express it with the existing operators, > > but already for three flags it's becoming clumsy and difficult to read: > > ^^ ( foo bar baz ( !foo !bar !baz ) ) > > Well, that could be written as: > ^^ ( foo bar baz ( !foo ) ) No, because that would (e.g.) disallow the combination "-foo +bar -baz". > In fact, going this way we could even go to: > ^^ ( foo bar baz ( ) ) That also doesn't work: To what should the empty group evaluate? False would just be a no-op here. And if it evaluates to true, then it would effectively be a "zero of" group. (In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Of course there are several ways to express it with the existing operators, > > > but already for three flags it's becoming clumsy and difficult to read: > > > ^^ ( foo bar baz ( !foo !bar !baz ) ) > > > > Well, that could be written as: > > ^^ ( foo bar baz ( !foo ) ) > > No, because that would (e.g.) disallow the combination "-foo +bar -baz". Sorry, you're right. > > > In fact, going this way we could even go to: > > ^^ ( foo bar baz ( ) ) > > That also doesn't work: To what should the empty group evaluate? False would > just be a no-op here. And if it evaluates to true, then it would effectively be > a "zero of" group. Hm, right, that's undefined. On the other hand, spec defines that it could be empty, and for the || and ^^ groups, it also defines that empty clauses count as being matched. Well, considering the above this does no longer matter. I missed the point. Meanwhile, some time has passed since introduction of EAPI 4, and REQUIRED_USE has found some use in the Portage tree. By a quick scan I found the following patterns: foo? ( !bar ) bar ( !foo ) Examples: faac? ( !aac ) aac? ( !faac ) gmthigh? ( !gmtfull ) gmtfull? ( !gmthigh ) opengl? ( !gles ) gles? ( !opengl ) pam? ( !skey ) skey? ( !pam ) pcsc-lite? ( !openct ) openct? ( !pcsc-lite ) portaudio? ( !pulseaudio ) pulseaudio? ( !portaudio ) xml? ( !expat ) expat? ( !xml ) Please note that one half of it would be sufficient, but for some reason people prefer to add extra redundancy in the majority of cases. ^^ ( ( !foo !bar ) ( foo !bar ) ( !foo bar ) ) Examples: ^^ ( ( !ruby !s7 ) ( ruby !s7 ) ( !ruby s7 ) ) ^^ ( ( !slurm !pbs ) ( slurm !pbs ) ( !slurm pbs ) ) Both of these cases could be expressed in a much clearer way (and without negation) as: ?? ( foo bar ) I found no usage cases where a general interval operator would be of advantage, so I retract this part of my proposal. The implementation in Portage should be easy: In function check_required_use the following change needs to be done: if operator == "||": return (True in argument) elif operator == "^^": return (argument.count(True) == 1) + elif operator == "??": + return (argument.count(True) <= 1) elif operator[-1] == "?": return (False not in argument) Additionally, ?? has to be added as another (EAPI dependent) alternative in all places where || and ^^ occur. Here's a patch for Portage: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ac843c3df2210566b559dc57c5fb657e20933a58 |