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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 7959 bytes --]

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


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

Those operators include both version and revision in the comparison.
They must be followed by a valid version with an optional revision
part. No revision is equal to -r0. Prefix match is not allowed.

Examples:

 [==1.3.3]             version 1.3.3, any revision
 [>1.3.3]              version >1.3.3 (e.g. 1.3.3.1 or 1.3.4...)
 [<=1.3.3]             version <=1.3.3 (incl. any revision of 1.3.3)
 [===1.3.3]            1.3.3-r0
 [>==1.3.3-r2]         1.3.3-r2 or newer
 [>=1.2,!=1.3.3]       version >=1.2 but not 1.3.3 (any revision)
 [>=1.2,<1.4]          version >=1.2 but <1.4
 [==1.2*]              any version starting with 1.2 prefix
 [>=1.2,<1.8,!=1.6*]   version >=1.2 but <1.8, also excluding 1.6*


Mapping from existing dependency syntax
=======================================

It should be noted that whenever revision match is desired, one of *==
operators need to be used. They do not include '<' or '>' variants, so
the revision needs to be decreased or increased appropriately for <==
or >==.

The behavior of current '~' operator is now equal to '==', so the
former is removed.

 =foo-1.2.3         ===1.2.3
 =foo-1.2.3-r3      ===1.2.3-r3
 =foo-1.2.3*        ==1.2.3*
 ~foo-1.2.3         ==1.2.3
 >foo-1.2.3         >==1.2.3-r1
 >foo-1.2.3-r9999   >1.2.3
 >=foo-1.2.3        >=1.2.3 or >==1.2.3
 >=foo-1.2.3-r3     >==1.2.3-r3
 <foo-1.2.3         <1.2.3
 <foo-1.2.3-r4      <==1.2.3-r3
 <=foo-1.2.3        <==1.2.3
 <=foo-1.2.3-r3     <==1.2.3-r3
 <=foo-1.2.3-r9999  <=1.2.3


Solutions to other problems
===========================

The provided operators make it possible to quite conveniently express
common types of dependencies. The remaining kinds can be constructed
using conjunctive ranges combined with existing operators.
In particular, for this specific reason the != and !== operators are
provided.

Disjunctive version ranges were considered needed rarely. If specific
versions needs to be excluded from the base version range, the !=
and !== operators (optionally in the prefix matching mode) can be used
to do so.

  [>=1.2,<1.6,!=1.4*,!=1.5*]

While I agree that this is not perfect and can become quite verbose at
times, the use cases for it are rather limited.

Revision ranges can be easily constructed using version ranges:

 [>==1.3-r3,<==1.3-r7]

Not that I see any real use for them.

Pre-release version ranges can be achieved using the relatively safe
_alpha_alpha or _p_p suffixes, or just predicting the upstream version
use.

The convenience Ruby ~> operator needs to be expanded to the verbose
range:

 [>=1.3.4,<1.4] or [>=1.3.4,==1.3*]


Rationale
=========

The key goal behind this concept is to optimize for upstream version
specifications, and provide the minimal reasonable, clear, symmetric
set of tools needed to achieve the correct dependencies.

The version syntax changes are necessary to be able to clearly express
version ranges, and also to distinguish old and new operators.
Furthermore, they increase the readability and usefulness of package
dependency specifications. The square braces and ordering are based
after Exherbo but can be changed if necessary.

The "," separator for versions is copied from USE dependencies which
are conjunctive as well. The disjunctive variant was not included since
our research has shown that it is used very rarely (i.e. only once
in the few base Exherbo repositories we've checked). Any more complex
logic would only make the dependencies less readable for unlikely
benefit.

The default behavior for new operators is meant to accommodate
the common necessity of expressing upstream version restrictions
in ebuilds. Its major advantage is that all the operators behave
symmetrically now (i.e. you don't have to add -r9999 to some of them to
match upstream constraints).

The additional ===, !==, >==, <== operators are provided to accommodate
Gentoo-specific revision constraints, and distinguish them from plain
upstream version constraints. No variant for '<' and '>' is provided
since the resulting syntax would be colliding or confusing, and all
possible revisions can be already expressed clearly using existing
operators.

Negations were added for the == and === equality operators to help
constructing version ranges. They also provide major readability
(and behavior) benefit over the current necessity of disallowing
single versions via blockers.

The prefix matching behavior was retained since it has its use cases.
Furthermore, it becomes useful with conjunctive version ranger to
disallow single versions matching a generic range.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

>>>>> On Thu, 10 Nov 2016, Michał Górny wrote:

> 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

I think we should stick to the existing operators, and not introduce
two slightly different sets for different contexts.

Especially:
- The operator for exact version match should be = not ==.
- Omit the != operator because it can be confused with blockers. If an
  operator for inequality is needed, we can add one but it should work
  everywhere (we could e.g. use <> for that).
- The ~ operator is missing.

> All those operators compare on versions ignoring the revision part.

I am strictly opposed to this. Again, it is confusing to have the same
operators acting in a different way depending on context.

> 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

These are not necessary if the regular operators match revision.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

On Thu, Nov 10, 2016 at 5:19 PM, Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 10 Nov 2016, Michał Górny wrote:
>
> > 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
>
> I think we should stick to the existing operators, and not introduce
> two slightly different sets for different contexts.
>
> Especially:
> - The operator for exact version match should be = not ==.
> - Omit the != operator because it can be confused with blockers. If an
>   operator for inequality is needed, we can add one but it should work
>   everywhere (we could e.g. use <> for that).
> - The ~ operator is missing.
>
> > All those operators compare on versions ignoring the revision part.
>
> I am strictly opposed to this. Again, it is confusing to have the same
> operators acting in a different way depending on context.
>
> > 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
>
> These are not necessary if the regular operators match revision.
>

Only if you're misusing revisions. A package depends on a another package,
not the ebuild revision of that package.

[-- Attachment #2: Type: text/html, Size: 2173 bytes --]

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

[Michael Orlitzky]

On 11/10/2016 07:03 PM, Gordon Pettey wrote:
> 
> Only if you're misusing revisions. A package depends on a another
> package, not the ebuild revision of that package.
> 

What if your package needs mine with SSL support, but mine was initially
committed without SSL support and -r1 adds it?

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

>>>>> On Thu, 10 Nov 2016, Gordon Pettey wrote:
   
>>   ===  exact version+revision match
>>   !==  exact version+revision non-match
>>   <==  version+revision less or equal to match
>>   >==  version+revision greater or equal to match
   
>     These are not necessary if the regular operators match revision.

> Only if you're misusing revisions. A package depends on a another
> package, not the ebuild revision of that package.

A revbump can be as large a change as an upstream version bump.
Usually the installed files will change, and there can be patches or
even security fixes. So I don't see why we would need to double the
number of operators, in order to distinguish between upstream bumps
and revbumps.

Note that we already have operators ignoring the revision for the two
most common cases, namely ~ and >= (i.e. >=cat/foo-1 will compare with
-r0, therefore ignoring the revision).

Also note that the suggested set of operators is incomplete. There are
"<== less than or equal to" and ">== greater than or equal to", but
the corresponding ones for "less than" and "greater than" are missing.
So this would remove part of the existing functionality.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[konsolebox]

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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]

On Fri, 11 Nov 2016 00:19:16 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 10 Nov 2016, Michał Górny wrote:  
> 
> > 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  
> 
> I think we should stick to the existing operators, and not introduce
> two slightly different sets for different contexts.
> 
> Especially:
> - The operator for exact version match should be = not ==.
> - Omit the != operator because it can be confused with blockers. If an
>   operator for inequality is needed, we can add one but it should work
>   everywhere (we could e.g. use <> for that).
> - The ~ operator is missing.
> 
> > All those operators compare on versions ignoring the revision part.  
> 
> I am strictly opposed to this. Again, it is confusing to have the same
> operators acting in a different way depending on context.
> 
> > 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  
> 
> These are not necessary if the regular operators match revision.

Most of your comments don't make sense if you are commenting on
the actual proposal. However, it seems that you immediately ignored
the core part of the proposal, and then commented on stupidity of some
distorted, imagined, half-ass proposal you imagined that lacks the core
part.

So, please, keep your comments on topic. If you don't like the proposal
(I didn't expect it to be otherwise), try at least to stay objective.
Because, really, complaining that proposal doesn't have '~' operator
means that you either didn't care to try to understand it, or that you
immediately discarded what you didn't like and complained on the result
you created yourself.

I expected more of you.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Fri, 11 Nov 2016 02:31:29 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> Also note that the suggested set of operators is incomplete. There are
> "<== less than or equal to" and ">== greater than or equal to", but
> the corresponding ones for "less than" and "greater than" are missing.
> So this would remove part of the existing functionality.

Which was quite thoroughly explained. But I can repeat it for you if
you insist: revisions are countable, so there's really no problem in
doing >== -r2 instead of > -r1, and <== -r2 instead of < -r3. With the
*== forms being IMHO cleaner since you clearly indicate the range of
revisions, without making someone wonder whether you didn't
accidentally forget = in there.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

>>>>> On Fri, 11 Nov 2016, Michał Górny wrote:

> Most of your comments don't make sense if you are commenting on the
> actual proposal. However, it seems that you immediately ignored the
> core part of the proposal, and then commented on stupidity of some
> distorted, imagined, half-ass proposal you imagined that lacks the
> core part.

I had merely addressed the following two points:

- The proposal would split the behaviour of the existing operators
  depending on context: a) They ignore the revision when in a [] group
  but don't when used in the traditional way, and b) syntax is changed
  unnecessarily, e.g. ~ vs == and = vs ===.

- The number of operators is doubled for no good reason. Revisions are
  not so special that they would justify that. In addition, if we
  limit the allowed range of revisions to 9999, the need for such
  operators will go away entirely. The most common cases (namely >=
  and ~) can be expressed already now, and the rather more rare
  less-than-or-equal-to-but-ignoring-revision can be expressed using
  r9999 (in those even more rare cases where a < comparison with the
  next PV doesn't work).

For both points the cost of the syntax change or of introducing
inconsistencies doesn't come with any benefit in the form of added
functionality.

> So, please, keep your comments on topic. If you don't like the
> proposal (I didn't expect it to be otherwise), try at least to stay
> objective. Because, really, complaining that proposal doesn't have
> '~' operator means that you either didn't care to try to understand
> it, or that you immediately discarded what you didn't like and
> complained on the result you created yourself.

> I expected more of you.

No comment on that part.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

On Fri, 11 Nov 2016 09:25:30 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Fri, 11 Nov 2016, Michał Górny wrote:  
> 
> > Most of your comments don't make sense if you are commenting on the
> > actual proposal. However, it seems that you immediately ignored the
> > core part of the proposal, and then commented on stupidity of some
> > distorted, imagined, half-ass proposal you imagined that lacks the
> > core part.  
> 
> I had merely addressed the following two points:
> 
> - The proposal would split the behaviour of the existing operators
>   depending on context: a) They ignore the revision when in a [] group
>   but don't when used in the traditional way, and b) syntax is changed
>   unnecessarily, e.g. ~ vs == and = vs ===.

The traditional way is only meant as a backwards compatibility
solution. I don't think we really should keep two syntax variants
supported forever, just because some developers are opposed to learn
anything new, and prefer contributing through every-half-a-year bursts
of drive-by commits.

Since the syntax needs to be changed anyway, why not introduce
a consistent set of operators instead of being forced to use whatever
was accidentally used years ago?

==, !=, <=, >= -- all consistent with one another. Same for ===, !==,
<==, >==. Using some old ~ and = wouldn't fit that. The gain is greater
than any benefit keeping old operator in a completely new syntax.

If you think it necessary, we can also change > to >> and to << to
have matching length for all relevant operators. Doesn't Debian do
that?

> - The number of operators is doubled for no good reason. Revisions are
>   not so special that they would justify that. In addition, if we
>   limit the allowed range of revisions to 9999, the need for such
>   operators will go away entirely. The most common cases (namely >=
>   and ~) can be expressed already now, and the rather more rare

That's non-symmetrical -> ugly. I'm proposing a pretty solution that
doesn't go and tell everyone else what is justified and what is not.

>   less-than-or-equal-to-but-ignoring-revision can be expressed using
>   r9999 (in those even more rare cases where a < comparison with the
>   next PV doesn't work).

That's a Gentoo policy. PMS applies outside Gentoo. Plus, do you really
find it convenient to type -r9999?

> For both points the cost of the syntax change or of introducing
> inconsistencies doesn't come with any benefit in the form of added
> functionality.

The cost of a major syntax change is pretty much the same. People have
to learn the new syntax and rewrite their dependencies anyway. Adding
a single '=' is a minor problem compared to the cost introduced by
ranges.

Plus, having a simpler way of expressing dependencies correctly also
changes things. Many developers were simply ignoring the correctness
right now as too hard to achieve. So the cost is still higher.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

>>>>> On Fri, 11 Nov 2016, Michał Górny wrote:

> ==, !=, <=, >= -- all consistent with one another. Same for ===,
> !==, <==, >==. Using some old ~ and = wouldn't fit that. The gain is
> greater than any benefit keeping old operator in a completely new
> syntax.

The gain is close to zero, if not even negative. I already pity new
dev candidates and their mentors:

"For equality, you must use = in a prefix context. In a postfix group
you have to use == instead. Note that == will ignore the revision
part. If you do not want that, add another equals sign to get ===.
However, for slot operators and in use conditional groups, equality is
denoted by = again. The != is a blocker in a prefix context, but in a
postfix context it means inequality, ignoring the revision."

> If you think it necessary, we can also change > to >> and to << to
> have matching length for all relevant operators. Doesn't Debian do
> that?

The problem is that you start from the premise that revisions are
somehow special. Their sole purpose is to distinguish downstream from
upstream versioning. They do not imply that the change to the package
is small. I simply don't see why we would need another set of
operators for explicit revision comparison.

So, here is a counter proposal, following the KISS principle as much
as possible:

1. Existing dependency syntax will be allowed indefinitely.

2. Version restrictions can go into a bracket delimited group
   after the package name, e.g. dev-foo/bar:4[>=4.11,<4.20].
   (Alternatively, parentheses () could be used instead of brackets.)

   a) Inside a group, the existing operators = < > <= >= ~ *
      have their established meaning.
   b) Several conditions can be combined (logical AND) with a comma.
   c) Old and new syntax must not be combined.
      For example, >=dev-foo/bar-4.11[<4.20] is not allowed.
   d) Empty [] groups are not allowed.

3. If necessary (personally, I don't think it is) we can add an
   operator for inequality with a consistent meaning in all contexts.
   Since the exclamation mark is used for blockers, <> could be used
   for that.

4. Revisions can be limited to 9999 by tree policy.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

On Fri, 11 Nov 2016 11:31:17 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> So, here is a counter proposal, following the KISS principle as much
> as possible:
> 
> 1. Existing dependency syntax will be allowed indefinitely.

As long as I'm not forced to use that crap, I'm fine with it.

> 2. Version restrictions can go into a bracket delimited group
>    after the package name, e.g. dev-foo/bar:4[>=4.11,<4.20].
>    (Alternatively, parentheses () could be used instead of brackets.)
> 
>    a) Inside a group, the existing operators = < > <= >= ~ *
>       have their established meaning.
>    b) Several conditions can be combined (logical AND) with a comma.
>    c) Old and new syntax must not be combined.
>       For example, >=dev-foo/bar-4.11[<4.20] is not allowed.
>    d) Empty [] groups are not allowed.
> 
> 3. If necessary (personally, I don't think it is) we can add an
>    operator for inequality with a consistent meaning in all contexts.
>    Since the exclamation mark is used for blockers, <> could be used
>    for that.

What about the negation of ~? It is more likely necessary than negation
of =.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

On Thu, 10 Nov 2016 23:53:40 +0100
Michał Górny <mgorny@gentoo.org> wrote:

>   dev-foo/bar[>=3][foo]        # version + USE

I kinda find this asking for problems with visual ambiguity.

Use different grouping symbols or supercede the USE syntax entirely.

   dev-foo/bar[foo]#(>=3)

Or something. I'm also suggesting here the possibility to define 2-symbol
openers instead of 1, like is common in quoting systems, eg:

  ${thingshere}
  #{thingshere}
  &{thingshere}

That way you have more wiggle room for more punctuation abuse later.

....orrr we could do away with punctuation abuse and make "[]" be a "Parameter space"


   dev-foo/bar[u:foo,v:>=3]

Where the general form is:

  [NAME:VAL,VAL,VAL,NAME:VAL,VAL]

Where

  NAME=u == "use requirement"
  NAME=v == "version requirement"

I know I'm painting a bike shed here, but I remember years ago suggesting the
last feature we added should have planned for a more future-extensible syntax,
and here we are again, bodging syntax entirely instead of simply extending the defined one.

Punctuation is precious and rare, and so you should exploit only as little as you need.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[konsolebox]

On Fri, Nov 11, 2016 at 10:37 PM, Kent Fredric <kentnl@gentoo.org> wrote:
> ....orrr we could do away with punctuation abuse and make "[]" be a "Parameter space"
>
>
>    dev-foo/bar[u:foo,v:>=3]

I got similar idea here, but my version is that you don't have to use
u: or v:.  When I was looking for the feature that 'foo[bar?]'
provides yesterday, I saw that the the special operators for use flags
don't conflict with the version operators.  And only use flags use
non-operator characters, so they could be used alone and
distinguishably without any.

dev-foo[>=3,foo]

So this time instead of using () for versions and [] for use flags, we
can just have [] for both.  Of course this again requires that
independent and rearrangeable version elements be implemented.

-- 
konsolebox

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Thu, 1 Dec 2016 14:53:51 +0800
konsolebox <konsolebox@gmail.com> wrote:

> I got similar idea here, but my version is that you don't have to use
> u: or v:

The entire point of defining it as a prefix-space was to avoid ambiguity,
and leave plenty of room for other such selector prefixes.

Relying on properties like "is it a number" or "is it text" is a shoddy
heuristic.

A heuristic that will fail us as soon as we want to add new features in
our matcher syntax.

Hence, 

   <ATOM>[<CONSTRAINT>(,<CONSTRAINT>...)]

   CONSTRAINT: <identifier>:<parameter>(,<parameter>...)


Then instead of debates about how we can invent some "new" syntax
where we have to constantly reinvent existing syntax to allow space
for the new syntax, we can just define new identifiers, because we thought
ahead about this problem and gave us wiggle room to add features.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[konsolebox]

On Sun, Dec 4, 2016 at 11:22 PM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Thu, 1 Dec 2016 14:53:51 +0800
> konsolebox <konsolebox@gmail.com> wrote:
>
>> I got similar idea here, but my version is that you don't have to use
>> u: or v:
>
> The entire point of defining it as a prefix-space was to avoid ambiguity,
> and leave plenty of room for other such selector prefixes.
>
> Relying on properties like "is it a number" or "is it text" is a shoddy
> heuristic.
>
> A heuristic that will fail us as soon as we want to add new features in
> our matcher syntax.
>
> Hence,
>
>    <ATOM>[<CONSTRAINT>(,<CONSTRAINT>...)]
>
>    CONSTRAINT: <identifier>:<parameter>(,<parameter>...)
>
>
> Then instead of debates about how we can invent some "new" syntax
> where we have to constantly reinvent existing syntax to allow space
> for the new syntax, we can just define new identifiers, because we thought
> ahead about this problem and gave us wiggle room to add features.

Well that's just it: ease of use and simplicity vs. portability with
possible new parameter types in the future; your pick.  I'll
personally go for the former this time.

Also, what kind of added type of parameters would you expect that
would be conflicting with USE flags, or other operators?  Wouldn't
adding another operator be enough, and not an identifying key?

I also find that the current features are already mature enough; we're
just enhancing it to have better control.  I don't expect anything big
to be added further.

And come to think of it, a parameter with a key can be distinguished
differently from a USE flag, because a USE flag wouldn't have a colon,
so a parameter with an identifier that defines its class can still be
added if with would need it in the future.

-- 
konsolebox

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

On Mon, 5 Dec 2016 01:21:34 +0800
konsolebox <konsolebox@gmail.com> wrote:

> Well that's just it: ease of use and simplicity vs. portability with
> possible new parameter types in the future; your pick.  I'll
> personally go for the former this time.
> 
> Also, what kind of added type of parameters would you expect that
> would be conflicting with USE flags, or other operators?  Wouldn't
> adding another operator be enough, and not an identifying key?
> 
> I also find that the current features are already mature enough; we're
> just enhancing it to have better control.  I don't expect anything big
> to be added further.

Its just frustrating for me, because its not the first time I've had this
conversation.

I have some vague memory of the last time we changed dependency syntax,
and I said then something along the lines of "hey, why not get this right so
we don't have to have this again later"

And here we are, bike shedding, debating new syntax classes without forsight.

> would be conflicting with USE flags, or other operators?  Wouldn't
> adding another operator be enough, and not an identifying key?

The difference between an "operator" and an "identifier" is one of the two
hails from a limited set of punctuation marks, and sometimes the order is
important.

For example: 5 + 6 and  add( 5, 6 ), are functionally equivalent, however,
the former hailed from a narrow supply of characters which people saw fit
to use for everything, and now you have fun problems in JavaScript where
"+" does more than one thing depending on conditions.

Punctuation is powerful, but its a limited resource that serves itself
best when used sparingly.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[konsolebox]

On Mon, Dec 5, 2016 at 1:41 AM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Mon, 5 Dec 2016 01:21:34 +0800
> konsolebox <konsolebox@gmail.com> wrote:
>
>> Well that's just it: ease of use and simplicity vs. portability with
>> possible new parameter types in the future; your pick.  I'll
>> personally go for the former this time.
>>
>> Also, what kind of added type of parameters would you expect that
>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>>
>> I also find that the current features are already mature enough; we're
>> just enhancing it to have better control.  I don't expect anything big
>> to be added further.
>
> Its just frustrating for me, because its not the first time I've had this
> conversation.
>
> I have some vague memory of the last time we changed dependency syntax,
> and I said then something along the lines of "hey, why not get this right so
> we don't have to have this again later"
>
> And here we are, bike shedding, debating new syntax classes without forsight.

I would love to prove this with a proof-of-concept, but I don't have
the motivation yet.  I also did it once, it wasn't helpful.

>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>
> The difference between an "operator" and an "identifier" is one of the two
> hails from a limited set of punctuation marks, and sometimes the order is
> important.
>
> For example: 5 + 6 and  add( 5, 6 ), are functionally equivalent, however,
> the former hailed from a narrow supply of characters which people saw fit
> to use for everything, and now you have fun problems in JavaScript where
> "+" does more than one thing depending on conditions.
>
> Punctuation is powerful, but its a limited resource that serves itself
> best when used sparingly.

I agree with that, but we have to consider balancing it a bit sometimes.

-- 
konsolebox