[gentoo-dev] Re: RFC: Future EAPI version operator changes

[Ulrich Mueller]

>>>>> On Sun, 6 Nov 2016, Michał Górny wrote:

> Following my previous RFC wrt version operator problems, I'd like to
> start the second part of the discussion: how to improve version
> operators in a Future EAPI?

> I've collected various ideas on operator changes on a wiki page [1].
> I've tried to stay open-minded and cover every possibility, even
> though I doubt some of them would be even considered.

> I should warn you that some of the solutions are interlinked to each
> other, and you probably need to look through the whole page first
> before starting to construct an opinion. For example, specific
> solutions to most of the problems depend on whether we enable
> version ranges and in which form.

> I think we should start by loosely discussing the various ideas
> on the wiki page. Feel free to also point out any missing ideas
> or remarks that would be useful there.

> So, what are your comments?

> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes

Thank you for collecting these ideas. As I see it, they can be divided
into two main categories: a) additional functionality and b) syntax
changes. IMHO we shouldn't go for any major syntax change in b),
unless this would be required by an important feature in a).

About the items on the wiki page:

> 1 Reordering to PACKAGE OP VERSION

This is a purely syntactical change. We should not do this without
good reason, i.e. additional functionality that cannot be expressed
with existing syntax.

> 2 Version ranges

I think this is a feature which is needed. However, I am not so sure
if a radical change of syntax would be necessary for it.

The most pressing problem seems to be that the current syntax cannot
specify a version range that must be within the same slot.
Introduction of a slot binding all-of group would solve this.

Looks like all the rest listed under the "version ranges" heading can
already be expressed with existing syntax, although in a verbose way.
So the question is if version ranges occur often enough to justify
introduction of a new and less verbose syntax?

> 3 Version suffixes and upper/lower bound problem

IMHO not worth the effort. Dependencies of "<" type don't occur very
often. Also I would expect that in most cases it will be known what
the next version is. And if not, the relation can still be expressed
with existing syntax (e.g. by appending an _alpha suffix).

> 4 Revision-related operators

Indeed we have some inconsistency there: We have ~ which is like =
but ignoring the revision, but we don't have corresponding operators
for the other four relations. The two ones corresponding to >= and <
would be redundant, though (because the normal >= and < operators
can be used with r0). This leaves us with > (ignoring revision)
and <= (ignoring revision).

Again, not sure how often this would be needed. Adding -r9999 is a
workaround for most (all?) cases occurring in practice.

Besides, what is special about revisions? A revbump potentially comes
with changes (like a security fix) as important as any upstream bump.
I can understand the need for the ~ operator, e.g., to keep packages
in sync that are built from the same upstream tarball. For inequality
relations I have doubts if we need anything revision specific.

> 5 Component-wide prefix comparison

I'd rather not introduce more creative ways how the * wildcard can be
abused. Maybe it could be dropped entirely, assuming we would have
version ranges.

Ulrich