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

[Ulrich Mueller]

> 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 , 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
  r (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


pgpPcUVI4kKm0.pgp
Description: PGP signature

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

[Michał Górny]

On Fri, 11 Nov 2016 09:25:30 +0100
Ulrich Mueller  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 , 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
>   r (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 -r?

> 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



pgppWiReaO78w.pgp
Description: OpenPGP digital signature

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

[Ulrich Mueller]

> 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  by tree policy.

Ulrich


pgp2sMR5sxTjE.pgp
Description: PGP signature

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

[Michał Górny]

On Fri, 11 Nov 2016 11:31:17 +0100
Ulrich Mueller  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



pgp7sRGtukgD8.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Thu, 10 Nov 2016 23:53:40 +0100
Michał Górny  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.



pgpJ78LZzAsW3.pgp
Description: OpenPGP digital signature

[gentoo-dev] Lastrites: app-misc/gramps-3.4.9

[Kevin Simmons]

# Kevin Simmons  (11 Nov 2016)
# Is holding up removal of old versions of
# sci-geosciences/osm-gps-map.
# Removal in 30 days.
app-misc/gramps-3.4.9