>>>>> On Tue, 15 Sep 2015, konsolebox wrote: > Here are my issues if we try to modify =* and not add another operator:
> 1) We'll completely abandon having an operator that matches the > remaining parts of a version number for good: =cat/foo-5.2015* would > no longer work. If you look at the history, this kind of string prefix matching was never intended. AFAICS, the "*" operator appeared in 2001 in Portage 1.6.12, and was first mentioned here: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/portage/files/1.5/pym/portage.py?r1=1.43&r2=1.44 The comment there says that it should match "really minor" versions and lists two examples: foo-1.0* will match 1.0.3, and glib-1.2* will match glib-1.2, glib-1.2-r1, glib-1.2.1 and glib-1.2.1.1-r1, but will not match glib-1.3. > 2) We'll have to decide if we should remove the leading zeros of a > version number: should 5.01.0 and and 5.1.2 be the matched the same > if I used =5.01*? Bad choice of example, as 5.01 and 5.1 are different versions (with 5.01 < 5.1 as one would expect). So, for a valid example you should ask instead: "Should 5.010.0 and 5.01.2 be matched the same if I used =5.010*?" > We can only either allow it or not. We keep one feature, we lose the > other feature. If we use another operator, =5.01* could just stay > strict on matching 5.01*, whereas the operator could have the > function of treating them like decimals instead. We can keep =* have > the string matching feature while have another operator do the > more-on-arithmetic one. We consider 5.01 and 5.010 as equal versions. Also note that =5.010 will match both of them. So the only sensible behaviour is if =5.010* matches all of 5.01, 5.010, 5.0100, 5.010.0, and 5.01.2. Having an operator that allows to distinguish between equal versions makes no sense. Ulrich
pgp6f2p7JMfCo.pgp
Description: PGP signature