[gentoo-dev] atom matching behavior

[gentoo-dev] atom matching behavior

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Repost from gentoo-portage-dev[1]:

Was just brought to my attention that the =* operator doesn't work as I
thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3.
This wouldn't be a bug problem if it could be used as a general glob
operator like with =foo-1.2.*, but it's use is strictly limited to the
above version (can only be used when a version component separator may
appear), so atm there is no facility to reliably lock an atom at a
specific version component when you have to account for multi-digit
components.
Now the question is if we want this glob-style behavior or not. From
the code comments it seems to be intentional, but I'd suspect that many
people share my original assumption and expect it to only match full
version components (as that is the much more common use case). Doesn't
help that the atom description in ebuild(5) doesn't specify the
behavior for this case either, 

"*  means  match  any version of the package so long as the specified
base is matched"

can be read both ways.

Opinions?

Marius

[1]
http://thread.gmane.org/gmane.linux.gentoo.portage.devel/2231/focus=2231

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] atom matching behavior

[Harald van Dijk]

On Thu, Aug 03, 2006 at 07:07:35AM +0200, Marius Mauch wrote:
> Repost from gentoo-portage-dev[1]:
> 
> Was just brought to my attention that the =* operator doesn't work as I
> thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3.
> This wouldn't be a bug problem if it could be used as a general glob
> operator like with =foo-1.2.*,

Even if that would be supported, it wouldn't match foo-1.2, unless
the meaning of * changes.

> but it's use is strictly limited to the
> above version (can only be used when a version component separator may
> appear), so atm there is no facility to reliably lock an atom at a
> specific version component when you have to account for multi-digit
> components.
> Now the question is if we want this glob-style behavior or not. From
> the code comments it seems to be intentional, but I'd suspect that many
> people share my original assumption and expect it to only match full
> version components (as that is the much more common use case). Doesn't
> help that the atom description in ebuild(5) doesn't specify the
> behavior for this case either, 
> 
> "*  means  match  any version of the package so long as the specified
> base is matched"
> 
> can be read both ways.
> 
> Opinions?
> 
> Marius

For packages with YYYYMMDD versions, =c/p-2005* can make sense, and
I have used this in the past. Please continue to allow that, and
possibly provide an alternative syntax for what you currently expect
=c/p-v* to do (=c/p-v.* -- if it doesn't require the . -- being a
possibility).
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] atom matching behavior

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

On Thursday 03 August 2006 01:44, Harald van Dijk wrote:
> On Thu, Aug 03, 2006 at 07:07:35AM +0200, Marius Mauch wrote:
> > Repost from gentoo-portage-dev[1]:
> >
> > Was just brought to my attention that the =* operator doesn't work as I
> > thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3.
> > This wouldn't be a bug problem if it could be used as a general glob
> > operator like with =foo-1.2.*,
>
> Even if that would be supported, it wouldn't match foo-1.2, unless
> the meaning of * changes.

as mentioned in the portage thread, the meaning of * doesnt really change as 
portage version information tends to be implicitly .0 extended
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] atom matching behavior

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Thursday 03 August 2006 07:07, Marius Mauch wrote:
> Opinions?
I actually tried to brought this in a few times, and mostly I was either 
ignored or told to live with it I think.

But I agree with you in requiring a solution. As Harald said, changing the 
behaviour "in the run" isn't a funny choice, probably adding 1.2.* that also 
accept 1.2 would be reasonable.

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] atom matching behavior

[Joshua Nichols]

Marius Mauch wrote:
> Repost from gentoo-portage-dev[1]:
>
> Was just brought to my attention that the =* operator doesn't work as I
> thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3.
> This wouldn't be a bug problem if it could be used as a general glob
> operator like with =foo-1.2.*, but it's use is strictly limited to the
> above version (can only be used when a version component separator may
> appear), so atm there is no facility to reliably lock an atom at a
> specific version component when you have to account for multi-digit
> components.
> Now the question is if we want this glob-style behavior or not. From
> the code comments it seems to be intentional, but I'd suspect that many
> people share my original assumption and expect it to only match full
> version components (as that is the much more common use case). Doesn't
> help that the atom description in ebuild(5) doesn't specify the
> behavior for this case either, 
>
> "*  means  match  any version of the package so long as the specified
> base is matched"
>
> can be read both ways.
>   
Many Java packages use =foo-1.2*, expecting to get like foo-1.2.1,
foo-1.2.3, etc. In these cases, it is actually intending to depend on a
particular slot, ie 1.2, but without slot dependencies, this is the next
best thing that can be done

--
Joshua Nichols
Gentoo/Java Project Lead
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] atom matching behavior

[Ciaran McCreesh]

On Thu, 3 Aug 2006 07:07:35 +0200 Marius Mauch <genone@gentoo.org>
wrote:
| "*  means  match  any version of the package so long as the specified
| base is matched"
| 
| can be read both ways.
| 
| Opinions?

Oooh! I have opinions!

If you're changing the dep behaviour, you might as well just do it
properly and add in :slot deps, which are a proper fix for this
problem...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] atom matching behavior

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Thu, 3 Aug 2006 16:59:01 +0100
Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk> wrote:

> On Thu, 3 Aug 2006 07:07:35 +0200 Marius Mauch <genone@gentoo.org>
> wrote:
> | "*  means  match  any version of the package so long as the
> specified | base is matched"
> | 
> | can be read both ways.
> | 
> | Opinions?
> 
> Oooh! I have opinions!
> 
> If you're changing the dep behaviour, you might as well just do it
> properly and add in :slot deps, which are a proper fix for this
> problem...

They aren't. They may cover many of the use cases here, but not all.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] atom matching behavior

[Stephen Bennett]

On Thu, 3 Aug 2006 07:07:35 +0200
Marius Mauch <genone@gentoo.org> wrote:

> Opinions?

Current behaviour is sub-optimal in many regards, but the tree relies
upon it; amongst other examples, packages depending upon =autoconf-2.5*
expect to get 2.59. If someone wants to 'fix' all of those, and any
other cases that may appear, I'd be for the change.
-- 
gentoo-dev@gentoo.org mailing list