| 1 |
On Fri, 11 Nov 2016 09:25:30 +0100 |
| 2 |
Ulrich Mueller <ulm@g.o> wrote: |
| 3 |
|
| 4 |
> >>>>> On Fri, 11 Nov 2016, Michał Górny wrote: |
| 5 |
> |
| 6 |
> > Most of your comments don't make sense if you are commenting on the |
| 7 |
> > actual proposal. However, it seems that you immediately ignored the |
| 8 |
> > core part of the proposal, and then commented on stupidity of some |
| 9 |
> > distorted, imagined, half-ass proposal you imagined that lacks the |
| 10 |
> > core part. |
| 11 |
> |
| 12 |
> I had merely addressed the following two points: |
| 13 |
> |
| 14 |
> - The proposal would split the behaviour of the existing operators |
| 15 |
> depending on context: a) They ignore the revision when in a [] group |
| 16 |
> but don't when used in the traditional way, and b) syntax is changed |
| 17 |
> unnecessarily, e.g. ~ vs == and = vs ===. |
| 18 |
|
| 19 |
The traditional way is only meant as a backwards compatibility |
| 20 |
solution. I don't think we really should keep two syntax variants |
| 21 |
supported forever, just because some developers are opposed to learn |
| 22 |
anything new, and prefer contributing through every-half-a-year bursts |
| 23 |
of drive-by commits. |
| 24 |
|
| 25 |
Since the syntax needs to be changed anyway, why not introduce |
| 26 |
a consistent set of operators instead of being forced to use whatever |
| 27 |
was accidentally used years ago? |
| 28 |
|
| 29 |
==, !=, <=, >= -- all consistent with one another. Same for ===, !==, |
| 30 |
<==, >==. Using some old ~ and = wouldn't fit that. The gain is greater |
| 31 |
than any benefit keeping old operator in a completely new syntax. |
| 32 |
|
| 33 |
If you think it necessary, we can also change > to >> and to << to |
| 34 |
have matching length for all relevant operators. Doesn't Debian do |
| 35 |
that? |
| 36 |
|
| 37 |
> - The number of operators is doubled for no good reason. Revisions are |
| 38 |
> not so special that they would justify that. In addition, if we |
| 39 |
> limit the allowed range of revisions to 9999, the need for such |
| 40 |
> operators will go away entirely. The most common cases (namely >= |
| 41 |
> and ~) can be expressed already now, and the rather more rare |
| 42 |
|
| 43 |
That's non-symmetrical -> ugly. I'm proposing a pretty solution that |
| 44 |
doesn't go and tell everyone else what is justified and what is not. |
| 45 |
|
| 46 |
> less-than-or-equal-to-but-ignoring-revision can be expressed using |
| 47 |
> r9999 (in those even more rare cases where a < comparison with the |
| 48 |
> next PV doesn't work). |
| 49 |
|
| 50 |
That's a Gentoo policy. PMS applies outside Gentoo. Plus, do you really |
| 51 |
find it convenient to type -r9999? |
| 52 |
|
| 53 |
> For both points the cost of the syntax change or of introducing |
| 54 |
> inconsistencies doesn't come with any benefit in the form of added |
| 55 |
> functionality. |
| 56 |
|
| 57 |
The cost of a major syntax change is pretty much the same. People have |
| 58 |
to learn the new syntax and rewrite their dependencies anyway. Adding |
| 59 |
a single '=' is a minor problem compared to the cost introduced by |
| 60 |
ranges. |
| 61 |
|
| 62 |
Plus, having a simpler way of expressing dependencies correctly also |
| 63 |
changes things. Many developers were simply ignoring the correctness |
| 64 |
right now as too hard to achieve. So the cost is still higher. |
| 65 |
|
| 66 |
-- |
| 67 |
Best regards, |
| 68 |
Michał Górny |
| 69 |
<http://dev.gentoo.org/~mgorny/> |
Archives