Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 16 September 2015 at 19:40, konsolebox wrote: > And I find it so wrong that it makes me think that it shouldn't have > been acknowledged by any packaging system. That versioning madness > should have been just fixed in the ebuilds level. Yeah. My experience with versions is its better to have a single versioning scheme that is regular and well defined, without any magical "Do everything different if this thing exists here" stuff. Perl versions suffer seriously from such logic, and gentoo also does, in different ways. The reason I believe we permitted versions to have such a variety of interpretations is to make it easier to track upstream versions 1:1. But in some places, that just makes our life more miserable for the attempt, and its more "Sane" to normalise upstream versions into a scheme that is consistent and makes sense. After all, that's what our downstream job is: To sanitize upstream for our users. And upstream *can* and *will* do utterly rediculous shit with versions that no single versioning syntax can ever attempt to adjust for. ( For instance, publishing versions with substrings of MD5s , where the textual data itself conveys absolutely no relativistic numeric value, because upstream don't care for progressive scales of versioning, only a "Have the latest version published or GTFO" mandate, which is something you can't map sanely ) Hence why perl herd bit that bullet a long time ago and applied a normalisation scheme, to map the horrible multiple-version-schemes system into a logical and consistent thing that gentoo handles simply. It comes with a price of course, that every ebuild has to have a "The upstream version is really ... " declaration, and people have to remember to change that when they bump the version, but it leads to much less dependency version confusions. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Wed, Sep 16, 2015 at 3:29 PM, konsolebox wrote: > On Tue, Sep 15, 2015 at 5:31 PM, Ulrich Mueller wrote: >>> On Tue, 15 Sep 2015, Ulrich Mueller wrote: >> > We consider 5.01 and 5.010 as equal versions. >> And do we still plan to keep them equal when we fix =*? >> >>> Yes. > > Makes me wonder. Are there even packages that still follow this > format? I.e. one that shifts from 2 digit to 3 digit format where it > intends to have the third digit as a subversion? And I find it so wrong that it makes me think that it shouldn't have been acknowledged by any packaging system. That versioning madness should have been just fixed in the ebuilds level.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 15 September 2015 at 06:54, Ulrich Mueller wrote: > >> I think it'd be okay to e.g. change the meaning and behavior of * in >> a new EAPI. > > Bug 560466 now. Assuming the syntax can be changed in a future EAPI. What EAPI applies to the use of these specifiers on the command line? What EAPI applies to the use of these specifiers in /etc/portage/** ? -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Tue, Sep 15, 2015 at 8:18 PM, Ciaran McCreesh wrote: > Semantic versioning is a new fad. I believe it's already been there for a while. It just didn't become a standard soon. > Certain upstreams still think that > 5.10 is a lower version that 5.2. Perl used to be notorious for doing > this, but they've partially changed in some places but not others. > > The rules are a mess because they need to a reasonable job of dealing > with all the crazy. But these rules may no longer be applicable with the current packages. Besides I think we can just enforce using 3 digits on versioning ebuilds when we see a package that uses both 2 digits and 3 digits.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Tue, Sep 15, 2015 at 5:31 PM, Ulrich Mueller wrote: >> On Tue, 15 Sep 2015, Ulrich Mueller wrote: > We consider 5.01 and 5.010 as equal versions. > >>> And do we still plan to keep them equal when we fix =*? > >> Yes. Makes me wonder. Are there even packages that still follow this format? I.e. one that shifts from 2 digit to 3 digit format where it intends to have the third digit as a subversion?
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Tue, 15 Sep 2015 16:54:59 +0800 konsolebox wrote: > Would that mean 5.1 is the same as 5.10? That's clearly illegal to > what most versioning schemes packages follow including the semantic > versioning (http://semver.org/). Semantic versioning is a new fad. Certain upstreams still think that 5.10 is a lower version that 5.2. Perl used to be notorious for doing this, but they've partially changed in some places but not others. The rules are a mess because they need to a reasonable job of dealing with all the crazy. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Tue, 15 Sep 2015, Ulrich Mueller wrote: >>> We consider 5.01 and 5.010 as equal versions. >> And do we still plan to keep them equal when we fix =*? > Yes. >> Would that mean 5.1 is the same as 5.10? > No. > RTFPMS, all the rules for version comparison are there: > https://projects.gentoo.org/pms/5/pms.html#x1-290003.3 Well, maybe the following is easier to remember. The general idea is that if any component (except for the first) starts with a 0 then it is considered a floating point number. Therefore: 5.1 < 5.10 (neither starts with a 0) 5.01 = 5.010 5.010 < 5.10 (first one starts with a 0) 5 = 05 (first component always uses integer comparison) 5.1_beta2 = 5.1_beta02 (suffixes always use integer comparison) However, the rule also applies if there are additional components before or after the one with the leading zeros, for example: 5.01.2 = 5.010.2 5.6.01 = 5.6.010 Ulrich pgphnwx4iuMgc.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Tue, 15 Sep 2015, konsolebox wrote: >> We consider 5.01 and 5.010 as equal versions. > And do we still plan to keep them equal when we fix =*? Yes. > Would that mean 5.1 is the same as 5.10? No. RTFPMS, all the rules for version comparison are there: https://projects.gentoo.org/pms/5/pms.html#x1-290003.3 pgp0X8t2kFich.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Tue, Sep 15, 2015 at 4:38 PM, Ulrich Mueller wrote: > We consider 5.01 and 5.010 as equal versions. And do we still plan to keep them equal when we fix =*? Would that mean 5.1 is the same as 5.10? That's clearly illegal to what most versioning schemes packages follow including the semantic versioning (http://semver.org/).
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> 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
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Tue, Sep 15, 2015 at 3:26 PM, konsolebox wrote: > Subslots are only applicable when creating ebuilds. Sorry I have to correct this. They are also applicable to other areas but not always sensible to use.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Tue, Sep 15, 2015 at 2:12 AM, Kristian Fiskerstrand wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 09/14/2015 06:35 AM, konsolebox wrote: >> So my suggestion is to add ~> as another operator. With it we can >> have an expression like '~>pkg-1.0.2a' and it would be equivalent >> to '>=pkg-1.0.2a' and '> '~>pkg-1.0.2' would be equivalent to '>=pkg-1.0.2' and >> ' > It strikes me that this likely is better solved using subslots, if it > is ABI compatability you're wishing to retain? Subslots are only applicable when creating ebuilds. And if I'm creating an ebuild, should I wait for the dependency to have a subslot? Also like I said earlier I find that slots are more for grouping but are not really specific to a parent version. It's also not always about ABI compatibility.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Tue, Sep 15, 2015 at 2:07 AM, Paweł Hajdan, Jr. wrote: > On 9/14/15 9:13 AM, konsolebox wrote: >> On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. >> wrote: >>> On 9/14/15 6:35 AM, konsolebox wrote: Many times we need to match packages like this: something-1.0.2a.* >>> >>> Could you give specific examples, i.e. what packages, what >>> dependencies, why is that needed? >> >> For accuracy and peace of mind regardless of how often conflicts >> could happen. > > I agree =pkg-4.1* also matching pkg-4.10 is a concern. > > In that case though, it would change the focus of the discussion to how > * operator should work, not necessarily adding a new ~> operator. 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. 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*? 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.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 9:53 PM, Manuel Rüger wrote: > Please don't add any more syntactic sugar to dependency strings. > People might become confused about stuff like this: > > =cat/foo-1.3.1_rc3_p20130829-r42+[!a=,!b?,c(+)]:3= =cat/foo-xyz+ is only one of the forms (we can still consider ~> or something else) but anyway, if we don't use another operator, would * no longer match strings like a glob matcher? For example, `=cat/foo-5.2015*` would no longer match cat/foo-5.20150102. On the other hand if we still allow to match like glob but have a workaround by allowing expressions like `=cat/foo-5.10.*`, we would now have to use 4 lines in order to accurately specify the targets: `=cat/foo-5.10`, `=cat/foo-5.10.*`, `=cat/foo-5.10-*` and `=cat/foo-5.10_*`. So should we no allow [.-_]* so we can reduce them to two? (Come to think of it, the @ operator is already used by sets so we can't have @cat/foo-5.10. But we can have =cat/foo-5.10@. Or =cat/foo-5.10~. But the latter could be found ambiguous or misinforming since ~cat/pkg-5.10 is already thought to only target revisions.) > Is there any real need to express this in a single line except for > saving a single line? There are areas where only a single expression is applicable like on a CLI query, or on package.* rules where applying or disabling a flag or keyword on specific version and unapplying or enabling the same flag or keyword on excluded versions may not always be sensible. Having to use more than a single expression adds noise and complexity.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, hasufell wrote: >> (Unless someone insists on a revision bump for each dependency >> modification > Yes, because everything else will cause a mess. Fortunately, for autotools.eclass it is a pure build-time dependency whose updating doesn't need any revbump. This leaves us with one single package with runtime dependencies. Ulrich pgpSKZzQPA5oR.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 09/14/2015 01:19 PM, hasufell wrote: > On 09/14/2015 09:56 PM, Andreas K. Huettel wrote: >> >> (Unless someone insists on a revision bump for each dependency modification > > Yes, because everything else will cause a mess. > Performing updates with a behavior like emerge --changed-deps gives similar results. Perhaps all package managers should enable this sort of behavior by default. -- Thanks, Zac
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Andreas K Huettel wrote: > Am Montag, 14. September 2015, 15:11:35 schrieb Ulrich Mueller: >> I could find only two instances of string prefix matching in the tree: >> >> - autotools.eclass depends on "=sys-devel/autoconf-2.1*" (with >> WANT_AUTOCONF=2.1). >> - media-video/nvidia-settings has "=x11-drivers/nvidia-drivers-3*". > How *could* you overlook the Perl virtuals? :) > (about 150 instances of =dev-lang/perl-5.22* or similar) Nope, these use the asterisk for matching of a version component range. So there is no string prefix ending in the middle of a component. In other words, =dev-lang/perl-5.22* matches version 5.22.0, so no version component is cut into pieces. Which is different for =sys-devel/autoconf-2.1* matching version 2.13. Ulrich pgpuECM3c8fwq.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 09/14/2015 09:56 PM, Andreas K. Huettel wrote: > > (Unless someone insists on a revision bump for each dependency modification Yes, because everything else will cause a mess.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Montag, 14. September 2015, 15:11:35 schrieb Ulrich Mueller: > > > The question is now... can we fix the spec? > > I could find only two instances of string prefix matching in the tree: > > - autotools.eclass depends on "=sys-devel/autoconf-2.1*" (with > WANT_AUTOCONF=2.1). > - media-video/nvidia-settings has "=x11-drivers/nvidia-drivers-3*". How *could* you overlook the Perl virtuals? :) (about 150 instances of =dev-lang/perl-5.22* or similar) However, these are standardized enough that any search/replace should be safe, given something has to be fixed. (I haven't followed the esoteric part of the discussion.) (Unless someone insists on a revision bump for each dependency modification - which is where I'd like to reply with an emphatic "Do it yourself then.") - -- Andreas K. Huettel Gentoo Linux developer (council, perl, libreoffice) dilfri...@gentoo.org http://www.akhuettel.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJV9yaJAAoJEB9VdM6hupKVQK8P/2IsZKEc+aAg+fkqyj+dikvt M40G6+WATRaQHKt7kXRbLfXXyJnjh3J2PyO2AHd3CKwh4jM52U4gEI5xiJDgNxEg pUdH9iR0tFx8ClC0ReaqfvRztizeQNCHiQgBtWzEMHp5BTB4F1NW/zD8juSAI1K6 kpp+Eei17uJjGM/tVQX1FQnZdhp/l/0Iq1bhDJtxpM2aqEcmmK7fipB8ko43EBF9 i38cfRq6feOYmtK7AE4yC0876uCMfTEIcCbGnwO/QIcOGEhvTAQ3vHINoe2W+3wU jnhxONhRAy4ss5E7XkdWF+xNXD9MFJ4Dbarkyr/miwSJhh+vVHKH6R2fXdc6QDAq xYmbWsMf9MG5zspJTx6whyJBUylcYPFH2FnyUrMPhuBpLv2AWeos1RVFruBZsWhG F3QkmXRUAhgqy34GMxLALjWD7EPrkiVV9GZFBirSF3xC23FrSpKYzduvRVLtv6+J UC+UJN/2dT1Ur+yg/c2ikMdBVviXXGqtDc9d30JVTeUpBDD/2B6cZJVcgUPP4TbP 2zQtMT4RZ3GI2sjCUgvcHPer1lVF8G6WHcnc+9uonawVyD0q8YhmHcjf+Csp4OCt PBNtiHmIqm/0Mzek8dHX9qHc6yl6iUwH11oBTiOdetZbWVdPAgSkewzmd/a552a3 jfHwEMTT/T1jdkI2MGDq =yFzT -END PGP SIGNATURE-
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Paweł Hajdan, wrote: > I agree =pkg-4.1* also matching pkg-4.10 is a concern. > In that case though, it would change the focus of the discussion to > how * operator should work, not necessarily adding a new ~> > operator. > I think it'd be okay to e.g. change the meaning and behavior of * in > a new EAPI. Bug 560466 now. Ulrich pgpuHmuPuih9Q.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/14/2015 06:35 AM, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* > > But that expression is not allowed with ~ (only targets revisions) > and neither with * (.*) is invalid. > > So my suggestion is to add ~> as another operator. With it we can > have an expression like '~>pkg-1.0.2a' and it would be equivalent > to '>=pkg-1.0.2a' and ' '~>pkg-1.0.2' would be equivalent to '>=pkg-1.0.2' and > '
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 9/14/15 9:13 AM, konsolebox wrote: > On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. > wrote: >> On 9/14/15 6:35 AM, konsolebox wrote: >>> Many times we need to match packages like this: >>> something-1.0.2a.* >> >> Could you give specific examples, i.e. what packages, what >> dependencies, why is that needed? > > For accuracy and peace of mind regardless of how often conflicts > could happen. I agree =pkg-4.1* also matching pkg-4.10 is a concern. In that case though, it would change the focus of the discussion to how * operator should work, not necessarily adding a new ~> operator. I think it'd be okay to e.g. change the meaning and behavior of * in a new EAPI. > I can't give any example yet, but we know that if pkg-4.1.2 exists > and pkg-4.10.0 exists as well, then we can't use '=pkg-4.1*' to only > target pkg-4.1.*. This could also happen more often with packages > having 4 version numbers. It's unfortunate this is rather theoretical now. Consider looking for some real examples, I believe this could really help the discussion. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, 14 Sep 2015 13:46:34 +0200 Ulrich Mueller wrote: > Interesting. So Portage follows the wording of the spec (prefix string > matching), whereas Paludis behaves like (IMHO) the spec should have > been written. Not so fast! Paludis has two different behaviours for =*, depending upon the context in which they're used. When parsing a user-supplied dependency specification, it uses the sane behaviour. When parsing something that's got an EAPI context, it uses the weird behaviour. You can't test this from the command line... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14.09.2015 10:41, konsolebox wrote: > On Mon, Sep 14, 2015 at 4:32 PM, konsolebox wrote: >> On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric wrote: >>> On 14 September 2015 at 20:22, konsolebox wrote: If we use an arithmetic operator like ~> then that could be decided >>> >>> As a counter proposal I'd suggest a different suffix character than >>> "*" instead. It just seems less confusing to have something like >>> >>> =cat/foo-1.30+ >>> >>> Instead of >>> >>> ~>cat/foo-1.30 >>> >>> Because ~> to me conveys some combination of ~ and > effects, when it >>> is neither of those two. >> >> I thought ~> is good as it's already famous to fellow Ruby users but I >> don't mind. =cat/foo-1.30+ seems good as well. > > @cat/foo-1.30 is also another. It only uses one symbol doesn't look > bad if negated: !@cat/foo-1.30 > Please don't add any more syntactic sugar to dependency strings. People might become confused about stuff like this: =cat/foo-1.3.1_rc3_p20130829-r42+[!a=,!b?,c(+)]:3= Is there any real need to express this in a single line except for saving a single line? - Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, hasufell wrote: > On 09/14/2015 01:46 PM, Ulrich Mueller wrote: >> Interesting. So Portage follows the wording of the spec (prefix >> string matching), whereas Paludis behaves like (IMHO) the spec >> should have been written. > The question is now... can we fix the spec? I could find only two instances of string prefix matching in the tree: - autotools.eclass depends on "=sys-devel/autoconf-2.1*" (with WANT_AUTOCONF=2.1). - media-video/nvidia-settings has "=x11-drivers/nvidia-drivers-3*". Both should be are easily fixable, in a way that doesn't break backwards compatibility with current Portage. So I think that fixing the spec would be possible, indeed. Ulrich pgpxjt4dASAsg.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 23:38, Ulrich Mueller wrote: >> That is, versions 1.020.3 and 1.02.3 will be considered equal. > It seems that it may not have been implemented that way . > Or am I expecting the wrong things when I read that logic and expect that: > emerge --ignore-default-opts -vaO =dev-lang/perl-5.022.0 > emerge --ignore-default-opts -vaO =dev-lang/perl-5.0220.0 > Should both match dev-lang/perl-5.22.0 ? No, 5.022.0 and 5.0220.0 are equal to each other, but they are not equal to 5.22.0. Algorithm 3 will remove any trailing zeros of the component, so you'll end up with "022", "022". and "22", which are compared using stringwise comparison. Ulrich pgp5YJzKOz0J9.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 09/14/2015 01:46 PM, Ulrich Mueller wrote: > > Interesting. So Portage follows the wording of the spec (prefix string > matching), whereas Paludis behaves like (IMHO) the spec should have > been written. > The question is now... can we fix the spec?
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > Portage: > emerge --ignore-default-opts -vpO =dev-lang/perl-5.2* > These are the packages that would be merged, in order: > [ebuild R] dev-lang/perl-5.22.0:0/5.22::gentoo USE="berkdb doc > gdbm -debug -ithreads" 0 KiB > Paludis: > cave resolve -1 -0 "*/*" =dev-lang/perl-5.2* > Done: 4 steps > These are the actions I will take, in order: > (nothing to do) > [...] Interesting. So Portage follows the wording of the spec (prefix string matching), whereas Paludis behaves like (IMHO) the spec should have been written. Ulrich pgpdmFPTB8AKm.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 23:38, Ulrich Mueller wrote: > Comparison in Algorithm 2 only takes place for the zeroth component > (i.e., "1", for the example above). > > For all following numeric components Algorithm 3 is called. For the > next component, the condition in line 1 is true, so it will remove > trailing zeros (i.e., both "020" and "02" will become "02") and then > it will use stringwise comparison. > > That is, versions 1.020.3 and 1.02.3 will be considered equal. It seems that it may not have been implemented that way . Or am I expecting the wrong things when I read that logic and expect that: emerge --ignore-default-opts -vaO =dev-lang/perl-5.022.0 emerge --ignore-default-opts -vaO =dev-lang/perl-5.0220.0 Should both match dev-lang/perl-5.22.0 ? -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 21:04, Ulrich Mueller wrote: >> Well, version comparison is described in [1] and it says that >> =cat/foo-1.020.3 will match cat/foo-1.02.3. > Surely, as per Algorithm 2, that is false, because "020" and "02" are > both integers, and therefor they'd default to integer comparison, and > "020" would be deemed ">" "02" Comparison in Algorithm 2 only takes place for the zeroth component (i.e., "1", for the example above). For all following numeric components Algorithm 3 is called. For the next component, the condition in line 1 is true, so it will remove trailing zeros (i.e., both "020" and "02" will become "02") and then it will use stringwise comparison. That is, versions 1.020.3 and 1.02.3 will be considered equal. Ulrich pgp64ceWpGSTn.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 21:04, Ulrich Mueller wrote: > Could someone check what is Paludis's behaviour for the examples > above? Also, does =cat/foo-1.2* match cat/foo-1.20 in Paludis? Portage: emerge --ignore-default-opts -vpO =dev-lang/perl-5.2* These are the packages that would be merged, in order: [ebuild R] dev-lang/perl-5.22.0:0/5.22::gentoo USE="berkdb doc gdbm -debug -ithreads" 0 KiB Paludis: cave resolve -1 -0 "*/*" =dev-lang/perl-5.2* Done: 4 steps These are the actions I will take, in order: (nothing to do) I encountered the following errors: ! dev-lang/perl Reasons: target Unsuitable candidates: * dev-lang/perl-5.20.2:0::gentoo Did not meet =dev-lang/perl-5.2*, never using existing, installing to / from target * dev-lang/perl-5.20.2-r1:0::gentoo Did not meet =dev-lang/perl-5.2*, never using existing, installing to / from target * dev-lang/perl-5.22.0:0::gentoo Did not meet =dev-lang/perl-5.2*, never using existing, installing to / from target -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 21:04, Ulrich Mueller wrote: > Well, version comparison is described in [1] and it says that > =cat/foo-1.020.3 will match cat/foo-1.02.3. Surely, as per Algorithm 2, that is false, because "020" and "02" are both integers, and therefor they'd default to integer comparison, and "020" would be deemed ">" "02" And that is most surely what happens in reality too, otherwise, surely, emerge --ignore-default-opts -vaO =dev-lang/perl-5.220.0 Would resolve to perl-5.22.0 Algorithm 3 should only fall into play if one or both of the compontents are non-numeric. Or is "leading 0" a "Non-numeric" condition? Either way, I'm glad nothing really scary happens when I do: emerge --ignore-default-opts -vaO =dev-lang/perl-5.0220.0 -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 20:01, Ulrich Mueller wrote: >> Which of the following will match the package "cat/foo-1.02.3", >> and why: >> >>=cat/foo-1.020.3 >>=cat/foo-1.020.3* >>=cat/foo-01.02.3* > Of those, I only expect the last to match, because leading 0's are > not typically significant. Well, version comparison is described in [1] and it says that =cat/foo-1.020.3 will match cat/foo-1.02.3. The problem is how to read the sentence "if the version specified has an asterisk immediately following it, a string prefix comparison is used instead" in the specification of the = operator [2]. Does that string prefix comparison apply to the whole version (then neither =cat/foo-1.020.3* nor =cat/foo-01.02.3* would match), or only to its last component (then both would match)? Portage behaviour is that =cat/foo-1.020.3* doesn't match but =cat/foo-01.02.3* does. Which seems to disagree with either reading of the spec. Could someone check what is Paludis's behaviour for the examples above? Also, does =cat/foo-1.2* match cat/foo-1.20 in Paludis? Ulrich [1] https://projects.gentoo.org/pms/5/pms.html#x1-290003.3 [2] https://projects.gentoo.org/pms/5/pms.html#x1-840008.2.6.1 pgpWOUt20Onhi.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 4:32 PM, konsolebox wrote: > On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric wrote: >> On 14 September 2015 at 20:22, konsolebox wrote: >>> If we use an arithmetic operator like ~> then that could be decided >> >> As a counter proposal I'd suggest a different suffix character than >> "*" instead. It just seems less confusing to have something like >> >> =cat/foo-1.30+ >> >> Instead of >> >> ~>cat/foo-1.30 >> >> Because ~> to me conveys some combination of ~ and > effects, when it >> is neither of those two. > > I thought ~> is good as it's already famous to fellow Ruby users but I > don't mind. =cat/foo-1.30+ seems good as well. @cat/foo-1.30 is also another. It only uses one symbol doesn't look bad if negated: !@cat/foo-1.30
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 4:28 PM, Kent Fredric wrote: > On 14 September 2015 at 20:22, konsolebox wrote: >> If we use an arithmetic operator like ~> then that could be decided > > As a counter proposal I'd suggest a different suffix character than > "*" instead. It just seems less confusing to have something like > > =cat/foo-1.30+ > > Instead of > > ~>cat/foo-1.30 > > Because ~> to me conveys some combination of ~ and > effects, when it > is neither of those two. I thought ~> is good as it's already famous to fellow Ruby users but I don't mind. =cat/foo-1.30+ seems good as well.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 20:22, konsolebox wrote: > If we use an arithmetic operator like ~> then that could be decided As a counter proposal I'd suggest a different suffix character than "*" instead. It just seems less confusing to have something like =cat/foo-1.30+ Instead of ~>cat/foo-1.30 Because ~> to me conveys some combination of ~ and > effects, when it is neither of those two. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 4:01 PM, Ulrich Mueller wrote: >> On Mon, 14 Sep 2015, Kent Fredric wrote: > >> On 14 September 2015 at 18:52, Ulrich Mueller wrote: > Another interesting example: Which of the following will match the > package "cat/foo-1.02.3", and why: > >=cat/foo-1.020.3 >=cat/foo-1.020.3* >=cat/foo-01.02.3* If we use an arithmetic operator like ~> then that could be decided easily. First we use a rule that all version numbers are decimal (oct is unlikely), so we simply remove the leading zeros then apply the rule accordingly, which is >=cat/foo-1.20.3 &&
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 20:01, Ulrich Mueller wrote: > We could fix this in a future EAPI such that version components would > not be split when matching. So =1.3* would not match 1.30 any more > because the 30 could only be matched as a whole. > > OTOH, I am not aware of any problems caused by the current behaviour. > Although I agree that it isn't logical There's a fringe use here which becomes more obvious with date-suffixed versions like 5.20150602 =5.2015* would be a legitimate and semi-useful condition for applying a mask for use flags etc. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 20:01, Ulrich Mueller wrote: >=cat/foo-1.020.3 >=cat/foo-1.020.3* >=cat/foo-01.02.3* Of those, I only expect the last to match, because leading 0's are not typically significant. However, that "=dev-lang/perl-05.22*" matches dev-lang/perl-5.22.0 but "=dev-lang/perl-5.022*" does not is a complete mystery to me. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > On 14 September 2015 at 18:52, Ulrich Mueller wrote: >> No, there isn't any dot implied. It uses simple prefix comparison, >> as in shell globbing. > Ugh. That's really really nasty. I'm going to have to go reprogram > my brain with bleach. :( > I say this because it doesn't strictly make sense in the knowledge > that 1.3 and 1.30 both match =1.3* We could fix this in a future EAPI such that version components would not be split when matching. So =1.3* would not match 1.30 any more because the 30 could only be matched as a whole. OTOH, I am not aware of any problems caused by the current behaviour. Although I agree that it isn't logical. Another interesting example: Which of the following will match the package "cat/foo-1.02.3", and why: =cat/foo-1.020.3 =cat/foo-1.020.3* =cat/foo-01.02.3* (Hint: PMS and Portage don't necessarily agree.) Ulrich pgpGCOjxBsrMO.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 2:29 PM, Paweł Hajdan, Jr. wrote: > On 9/14/15 6:35 AM, konsolebox wrote: >> Many times we need to match packages like this: something-1.0.2a.* > > Could you give specific examples, i.e. what packages, what dependencies, > why is that needed? For accuracy and peace of mind regardless of how often conflicts could happen. I want to write rules in /etc/portage/package.* and specify dependencies in ebuilds without minding that one atom expression could unexpectedly match another package version on later time. I can't give any example yet, but we know that if pkg-4.1.2 exists and pkg-4.10.0 exists as well, then we can't use '=pkg-4.1*' to only target pkg-4.1.*. This could also happen more often with packages having 4 version numbers.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 18:52, Ulrich Mueller wrote: > It does, in fact. > >> When it only matches 1.0.2 and 1.0.2.* > >> You're reading it in shell glob notation and not the portage notation, >> that the trailing dot is *implied*, > > No, there isn't any dot implied. It uses simple prefix comparison, as > in shell globbing. > >> which is why explictly stating it is illegal. > > Explicitly stating the dot is illegal, because without the asterisk it > must still be a valid version specification. Ugh. That's really really nasty. I'm going to have to go reprogram my brain with bleach. :( I say this because it doesn't strictly make sense in the knowledge that 1.3 and 1.30 both match =1.3* So there is, as he describes, no proviso for "X, or some subversion of it". Thus, the documentation is very misleading, as although "1.2*" will match "1.2.x" and not "1.1.x" and not "1.3.x", it will also match 1.20.x , and that fact is a footgun waiting to go off. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, Kent Fredric wrote: > I don't believe it works that way. > That would imply > =pkg-1.0.2* would match 1.0.20 It does, in fact. > When it only matches 1.0.2 and 1.0.2.* > You're reading it in shell glob notation and not the portage notation, > that the trailing dot is *implied*, No, there isn't any dot implied. It uses simple prefix comparison, as in shell globbing. > which is why explictly stating it is illegal. Explicitly stating the dot is illegal, because without the asterisk it must still be a valid version specification. Ulrich pgpJ1DlPkzbV2.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 2:19 PM, Kent Fredric wrote: > On 14 September 2015 at 18:09, konsolebox wrote: >> Because they could also match pkg-1.0.2aa > > That would imply > > =pkg-1.0.2* would match 1.0.20 > > When it only matches 1.0.2 and 1.0.2.* > > You're reading it in shell glob notation and not the portage notation, > that the trailing dot is *implied*, which is why explictly stating it > is illegal. Test shows that it doesn't work that way. Here I created a dummy bash-4.30: # emerge -pvO =app-shells/bash-4.3_p42 These are the packages that would be merged, in order: [ebuild U ~] app-shells/bash-4.3_p42::gentoo [4.3_p39::gentoo] USE="net nls (readline) -afs -bashlogger -examples -mem-scramble -plugins -vanilla" 6 KiB Total: 1 package (1 upgrade), Size of downloads: 6 KiB # emerge -pvO '=app-shells/bash-4.3*' These are the packages that would be merged, in order: [ebuild U ~] app-shells/bash-4.30::local [4.3_p39::gentoo] USE="net nls (readline) -afs -bashlogger -examples -mem-scramble -plugins -vanilla" 0 KiB Total: 1 package (1 upgrade), Size of downloads: 0 KiB # ls /var/db/pkg/sys-apps/portage-2.2.20.1/ > https://devmanual.gentoo.org/general-concepts/dependencies/index.html#ranged-dependencies > >> To specify "version 2.x (not 1.x or 3.x)" of a package, it is necessary to >> use the asterisk postfix. >> Note that the equals sign is mandatory, and that there is no dot before the >> asterisk. The provided example was `DEPEND="gtk? ( =x11-libs/gtk+-1.2* )"`. I'm not sure if that was accurately implying "version 1.2.x (not 1.1.x or 1.3.x)".
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 9/14/15 6:35 AM, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* Could you give specific examples, i.e. what packages, what dependencies, why is that needed? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 18:09, konsolebox wrote: > Because they could also match pkg-1.0.2aa I don't believe it works that way. That would imply =pkg-1.0.2* would match 1.0.20 When it only matches 1.0.2 and 1.0.2.* You're reading it in shell glob notation and not the portage notation, that the trailing dot is *implied*, which is why explictly stating it is illegal. https://devmanual.gentoo.org/general-concepts/dependencies/index.html#ranged-dependencies > To specify "version 2.x (not 1.x or 3.x)" of a package, it is necessary to > use the asterisk postfix. > Note that the equals sign is mandatory, and that there is no dot before the > asterisk. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 1:38 PM, Daniel Campbell wrote: > Honestly, this situation looks like a perfect candidate for slotting > instead of adding a new feature. If SLOT is setup correctly between > ebuilds, you could check to be sure it's a specific SLOT. So in your > case, pkg-1.0.2[a-z] would be slotted with e.g. pkg-1.0.2g:1.0.2. > Anything depending on it would use `pkg:1.0.2`, and the pkg-1.0.3a > ebuild could use SLOT="1.0.3" and be called as a dependency via > `pkg:1.0.3`. Slotting means isolation (most of the time as a group and not necessarily on a parent version), but that's not always the case when you're just wanting to target a specific version. With the operator we could avoid unnecessary overkill using slots. Also that would only apply when you're creating an ebuild.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On Mon, Sep 14, 2015 at 1:51 PM, Ulrich Mueller wrote: > Sorry, but I don't get it. How would these be different from the > existing "=pkg-1.0.2a*" and "=pkg-1.0.2*"? Because they could also match pkg-1.0.2aa (not sure if it's still valid atom) and pkg-1.0.20 respectively.
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
> On Mon, 14 Sep 2015, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* > But that expression is not allowed with ~ (only targets revisions) > and neither with * (.*) is invalid. > `So my suggestion is to add ~> as another operator. With it we can > have an expression like '~>pkg-1.0.2a' and it would be equivalent to > '>=pkg-1.0.2a' and ' '~>pkg-1.0.2' would be equivalent to '>=pkg-1.0.2' and ' pgpTEWYXQ55Q7.pgp Description: PGP signature
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
On 14 September 2015 at 16:35, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* > > But that expression is not allowed with ~ (only targets revisions) and > neither with * (.*) is invalid. What does =cat/pkg-something-1.0.2a* do? ( note, lack of . before * ) Why is that undesirable? IME, when you write ".*" you mean to write "*". That's what the "*" implies: version X or version X.Any https://devmanual.gentoo.org/general-concepts/dependencies/index.html#ranged-dependencies -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/13/2015 09:35 PM, konsolebox wrote: > Many times we need to match packages like this: something-1.0.2a.* > > But that expression is not allowed with ~ (only targets revisions) > and neither with * (.*) is invalid. > > So my suggestion is to add ~> as another operator. With it we can > have an expression like '~>pkg-1.0.2a' and it would be equivalent > to '>=pkg-1.0.2a' and ' '~>pkg-1.0.2' would be equivalent to '>=pkg-1.0.2' and > ' > If comparing by arithmetic operations turns out to be difficult > (i.e. predicting the next version to compare against), then maybe > we could just compare it with pattern(s). For example if we have > 'pkg-1.02a' as the base version, then the valid versions we need to > get are 'pkg-1.02a', 'pkg-1.02a.*' and > 'pkg-1.02a(_(alpha|beta|pre|p)|-r)[0-9]+'. > > The operator is copied from Ruby's Gemfile so it would be familiar > to anyone developing Ruby as well. > Honestly, this situation looks like a perfect candidate for slotting instead of adding a new feature. If SLOT is setup correctly between ebuilds, you could check to be sure it's a specific SLOT. So in your case, pkg-1.0.2[a-z] would be slotted with e.g. pkg-1.0.2g:1.0.2. Anything depending on it would use `pkg:1.0.2`, and the pkg-1.0.3a ebuild could use SLOT="1.0.3" and be called as a dependency via `pkg:1.0.3`. Just my two cents. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV9l1KAAoJEAEkDpRQOeFwM4gQANPEqNiTHQDU55eH//Iw3KVw W3U2DoPR1YuxALF4vCrxDACcHxtwR0k7L7j54Hkpc6y8V93z9aJIEj396ktNSmk9 BYGzH+M/IO4VsEjm9Ns9GZn4fxQ2YUw3v7SVq+kqmBDNwkKU/5ZsR2XaGykQSuMQ smTuZCCILdx3/6QfKQvvk6tuA6kEzLIuCpXE8l56uXJJzpKb+syWSefZftO31PU4 Qbj8zWlRMNoUEEQpJT7yTEzrfvRvFsMPPiHKUYw05WxjuQZzf52GZSdvBMDTTqGu Ltf4BjSF/4c01zMmh3qMKmIiVzCq4pGLv0IcQ0DJmh8KAzYGP++Y+deAHLztyVGu Fx793wps+/ZdfY86QQ+NFD9QHUT8RLCRvr+87YmNwQqxwQCErBF1KeQfbw0NB4m9 tyegRLXgiVlR9yDIo736vTyxPwHe9xtOtFMsOQRPIfKI3T8KzZlxEsAj7kfoMX16 eKeeJlKB2WU4wQ6tbDm3Gjjk0dZmVrU7ZAnVwG5KbXtz4oPp+rwbyX4fn8uG9rVB XVJfLfJjXtkjFliFeUAKdRcm9ZyuKTO5BIppC7RCajEaHkuXSCRoBu7RpbwkyT+V IMBz0Y6/dZyHMplfp5UGIqPMyUqYKQXh1MREro9xqSisxwf9RpDVj38OrbvjdvRW 7uilEYxSlijwOnWeCvG6 =EtOQ -END PGP SIGNATURE-
[gentoo-dev] Request to add ~> atom prefix operator on Portage.
Many times we need to match packages like this: something-1.0.2a.* But that expression is not allowed with ~ (only targets revisions) and neither with * (.*) is invalid. So my suggestion is to add ~> as another operator. With it we can have an expression like '~>pkg-1.0.2a' and it would be equivalent to '>=pkg-1.0.2a' and 'pkg-1.0.2' would be equivalent to '>=pkg-1.0.2' and '