Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[konsolebox]

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.

[konsolebox]

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.

[Kent Fredric]

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.

[konsolebox]

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.

[Kent Fredric]

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.

[konsolebox]

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.

[konsolebox]

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.

[konsolebox]

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.

[konsolebox]

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.

[Ulrich Mueller]

> 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=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.

[konsolebox]

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.

[Ulrich Mueller]

> 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.

[Ulrich Mueller]

> 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.

[Ciaran McCreesh]

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.

[Ulrich Mueller]

> 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.

[Ulrich Mueller]

> 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.

[Kent Fredric]

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.

[Ulrich Mueller]

> 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.

[Ulrich Mueller]

> 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.

[hasufell]

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.

[Manuel Rüger]

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.

[Ciaran McCreesh]

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.

[Ulrich Mueller]

> 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.

[Zac Medico]

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.

[hasufell]

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.

[Ulrich Mueller]

> 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.

[Ulrich Mueller]

> 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.

[konsolebox]

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.

[Ulrich Mueller]

> 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.

[konsolebox]

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.

[Kent Fredric]

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.

[Paweł Hajdan , Jr .]

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.

[Kristian Fiskerstrand]

-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.

[Andreas K. Huettel]

-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.

[Ulrich Mueller]

> 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.

[konsolebox]

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.

[Kent Fredric]

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.

[Paweł Hajdan , Jr .]

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.

[konsolebox]

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.

[Kent Fredric]

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.

[konsolebox]

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.

[Kent Fredric]

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.

[Kent Fredric]

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.

[Kent Fredric]

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.

[konsolebox]

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.

[Kent Fredric]

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.

[konsolebox]

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.

[Ulrich Mueller]

> 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.

[Kent Fredric]

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.

[Ulrich Mueller]

> 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 '

Re: [gentoo-dev] Request to add ~> atom prefix operator on Portage.

[Daniel Campbell]

-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-