On Fri, Nov 11, 2016 at 6:53 AM, Michał Górny <mgo...@gentoo.org> wrote: > Hello, everyone. > > Following my earlier threads, I'd like to propose a first complete > solution for new version restrictions for package dependencies. I > honestly doubt it's going to be approved since it's a major change. > Nevertheless, I think it's an interesting topic for consideration. > > What is included: > > - conjunctive version ranges, > - revision-free and revision-oriented comparisons, > - full set of (blocker-free) logical operators. > > What isn't included: > > - disjunctive version ranges, > - complete lower bound problem solution, > - extensions for prefix matching, > - some convenience shortcuts like Ruby's ~> op. > > > Backwards compatibility [recommended] > ===================================== > > For backwards compatibility, package dependency specifications using > old-style restrictions will still be accepted. Those specifications > will retain the old behavior, and have no new features. > > > New package dependency syntax > ============================= > > New-style package dependencies use the following syntax: > > <cat> "/" <pkg> [":" <slot>] ["[" <vers> "]"] ["[" <usedep> "]"] > > with <vers> now using the following sub-syntax: > > <op> <version> ["," <op> <version>...] > > The version restriction operator is removed from the front and all > package dependency specifications start with the category and package > name, followed by optional package slot. This can be followed by > optional version restrictions and USE flag restrictions. > > The version constraints (if present) must *always* be placed inside > square brackets, even for a single constraint. Each constraint starts > with an operator followed by a version string. Multiple constraints are > separated using "," character, and are conjunctive (AND-ed). > > The operators are not valid for beginning of a USE dependency string, > therefore the version constraint can be clearly distinguished from USE > contraints. > > The version and USE flag constraints are always disjoint. If both are > present, they must be surrounded by separate pairs of brackets. > > Examples: > > dev-foo/bar:13[foo] # slot + USE > dev-foo/bar[>=3] # single version constraint > dev-foo/bar:4[>=4.11,<4.20] # slot + version range > dev-foo/bar[>=3][foo] # version + USE
Looks like you excluded the independent rearrangeability of the conditional elements, and the OR feature; and also, grouping being optional where AND would be the default control operator. Does that still allow multi-level grouping? You can choose to have such restrictions now, but I still highly suggest the use of () instead of [], so it would be clear that [] is for use flags, and () is for versions. Not only would that lessen confusion and remove the parser's necessity to look-ahead-and-verify, it would also make the syntax open to future improvements. The use of comma as a separator looks good, and minimizes the characters that the parser would have to check when checking for a new token. > Version restrictions > ==================== > > Each version restriction consists of an operator followed by a version > string. > > The following revision-free version comparison operators are provided: > > == exact version match, or prefix match (with *) > != exact version non-match, or prefix non-match (with *) > < version less than match > <= version less or equal to match > > version greater than match > >= version greater or equal to match > > All those operators compare on versions ignoring the revision part. > They must be followed by a valid version with no revision part. > Additionally, the == and != operators can accept a version followed by > * to indicate prefix match. > > The following revision-oriented version comparison operators are > provided: > > === exact version+revision match > !== exact version+revision non-match > <== version+revision less or equal to match > >== version+revision greater or equal to match I doubted this at first but after further examination I found that it's actually more consistent. It's more aggressive but it's a more correct solution. -- konsolebox
