>>>>> 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
pgp1hK3XYbh3_.pgp
Description: PGP signature
