Re: [gentoo-dev] [RFC] New version constraints: variant one

[konsolebox]

On Fri, Nov 11, 2016 at 6:53 AM, Michał Górny <mgorny@g.o> 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