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
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
> 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. :(
>
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-lan
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*" an
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 th
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
>=
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
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 hav
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 charact
> 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 mat
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
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,
> 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 int
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 rem
> 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
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?
> 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 exp
> 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 spe
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 p
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 con
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
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
-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 a
> 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 meani
-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*
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.
> 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-vi
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
> 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 leave
I contacted Robin today asking for how to proceed
here, he told me to post here.
tl;dr ->
https://bugs.gentoo.org/show_bug.cgi?id=506052
shows that
* the former dev has removed himself as maintainer
* the package is rather outdated now in portage
* there are some ebuilds already which could
31 matches
Mail list logo
