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

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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] RFI: A better workflow for github pull requests

2015-09-14 Thread Brian Dolbec 
On Sun, 13 Sep 2015 15:37:17 +0200
Michał Górny  wrote:

> Dnia 13 września 2015 11:48:54 CEST, Jason Zaman
>  napisał(a):
> >On Sat, Sep 12, 2015 at 09:12:25PM +0200, Michał Górny wrote:
> >> Potential solution: bi-dir github <=> bugzilla integration
> >> ==
> >> 
> >> My current idea would be pretty much that:
> >> 
> >> 1. a new dedicated Gentoo bug would be automatically created for
> >every
> >> pull request on github,
> >
> >Will this be only github PR's? will github issues be mirrored too? or
> >are the issues not supposed to be used on github at all?
> 
> Issues are already disabled and I don't see any point in enabling
> them.
> 

I've been doing github api work in my new job.  Pull-requests ARE
issues, just a special version of an issue is all.  Your suppose to be
able to call up the pull request number using the same number in an
issue call.

Do you mean the issue tracker is disabled?  Then they are only allowing
pull request issues, not general issues.

> >
> >Also, I think the new bugzie version allows multiple aliases on a
> >bug, so can we automomatically assign them github-pr-123 and
> >github-issue-234
> >etc?
> 
> Sounds good.
> 
> >
> >> What are your thoughts? Any other proposals?
> >
> >Overall I like the idea. I think the quoting and other issues can be
> >fixed in an acceptable way.
> >
> >-- Jason
> 
> 



-- 
Brian Dolbec

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

2015-09-14 Thread 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

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

2015-09-14 Thread Duncan 
konsolebox posted on Mon, 14 Sep 2015 14:09:03 +0800 as excerpted:

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

What about combining (positive) deps and blockers, deping on =pkg-1.0.2a* 
and blocking >=pkg-1.0.2b ?  Wouldn't that resolve the unintended matches?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

2015-09-14 Thread 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] RFI: A better workflow for github pull requests

2015-09-14 Thread Pacho Ramos 
El lun, 14-09-2015 a las 00:19 +0300, Andrew Savchenko escribió:
[...]
> Yes, but as long as choice of core components and infrastructure is
> free one. Read Gentoo Social Contract:
> 
> https://www.gentoo.org/get-started/philosophy/social-contract.html
> 
> "However, Gentoo will never depend upon a piece of software or
> metadata unless it conforms to the GNU General Public License, the
> GNU Lesser General Public License, the Creative Commons -
> Attribution/Share Alike or some other license approved by the Open
> Source Initiative (OSI)."
> 
> What actually happens now is that several individual are trying to
> undermine this concept and to tie Gentoo to the proprietary
> metadata. And some point this dependence will become irreversible.
> It is a pain for me to see that several developers under disguise of
> "community" and "integration" are trying hard to make that happen,
> step by step.
> 
> Best regards,
> Andrew Savchenko

I completely disagree with you pointing to some concrete people and
accusing them about they trying to break the social contract. I see no
proof at all to support your accusation, and I think you should refrain
from doing that kind of accusations without any base. If you have any
kind of "proof" supporting that accusations, please explain them
briefly, otherwise this looks just like trolling to me :/

The only thing I see here is some people trying to mirror github and
bugzilla, and that will likely help a lot of people (like me) that
don't use github, letting people that need their features to work with
other people that don't need or don't want to use it. What is the
problem then? :| Why people tend to think that others have obscure
intentions or similar? Isn't much easier to think that all people here
are contributing for free for the sake of improving things? Why do we
need to be so rude when discussing things on mailing lists or IRC? I am
sure that if we could meet in the "real life", face to face, we would
see that there are no conspiracies and no obscure intentions and most
of the arguments come from misunderstandings, overreactions and similar
:|

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

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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] Re: Request to add ~> atom prefix operator on Portage.

2015-09-14 Thread konsolebox 
On Mon, Sep 14, 2015 at 3:58 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> konsolebox posted on Mon, 14 Sep 2015 14:09:03 +0800 as excerpted:
>
>> 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.
>
> What about combining (positive) deps and blockers, deping on =pkg-1.0.2a*
> and blocking >=pkg-1.0.2b ?  Wouldn't that resolve the unintended matches?

Possible workaround but all I'd say is that it adds complexity or
noise.  We also do other things besides blocking.  Sometimes we just
call dependencies, sometimes we just apply or disable flags - such are
the cases where doing the opposite action to excluded versions is not
always applicable.

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

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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.

2015-09-14 Thread 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