---
lib/bb/providers.py | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/lib/bb/providers.py b/lib/bb/providers.py
index 8970fb3..feaee52 100644
--- a/lib/bb/providers.py
+++ b/lib/bb/providers.py
@@ -63,7 +63,18 @@ def sortPriorities(pn, dataCache, pkg_pn = None):

return tmp_pn

+def isPreferredVersion(pe, pv, pr, preferred_e, preferred_v, preferred_r):
+ """
+ Check if the version pe,pv,pr is the preferred one.
+ If there is preferred version defined and ends with '%', then pv has to start with that version after removing the '%' in the end,
+ """

+ if (pv == preferred_v or (preferred_v != None and preferred_v.endswith('%') and pv.startswith(preferred_v[:len(preferred_v)-1]))):
+ if (pr == preferred_r or preferred_r == None):
+ if (pe == preferred_e or preferred_e == None):
+ return true
+ return false
+
def findPreferredProvider(pn, cfgData, dataCache, pkg_pn = None, item = None):
"""
Find the first provider in pkg_pn with a PREFERRED_VERSION set.
@@ -96,7 +107,7 @@ def findPreferredProvider(pn, cfgData, dataCache, pkg_pn = None, item = None):
for file_set in pkg_pn:
for f in file_set:
pe,pv,pr = dataCache.pkg_pepvpr[f]
- if preferred_v == pv and (preferred_r == pr or preferred_r == None) and (preferred_e == pe or preferred_e == None):
+ if isPreferredVersion(pe,pv,pr,preferred_e,preferred_v,preferred_r):
preferred_file = f
preferred_ver = (pe, pv, pr)
break
--
1.6.4.2

On Mon, Sep 14, 2009 at 12:43 AM, Martin Jansa <martin.jansa@...>wrote:

---
lib/bb/providers.py | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)

As I'm not python programmer, I should at least test it better :/ sorry for
that noise.
true->True, false->False

better version in attachment

I personally like the idea but could you make clear your usercase?

--
Otavio Salvador O.S. Systems
E-mail: otavio@... http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

On Mon, Sep 14, 2009 at 01:39:50PM -0300, Otavio Salvador wrote:

I personally like the idea but could you make clear your usercase?

I had problem when using _git or _svn versions with AUTOREV.

When there is SRCREV or SRCPV in PV of that bb file you would like to use then
you need to update PREFERRED_VERSION_pkg with every new commit or just
make sure that _git or _svn version has highest DEFAULT_PREFERENCE.

Setting DEFAULT_PREFERENCE to -1 in all non _git bb files is bad,
because then every distro using that package will get pkg_git.bb, in
contrast to setting PREFERRED_VERSION_pkg for just one distro or machine.

With this wildcard I can set ie
PREFERRED_VERSION_xserver-xorg = "1.6.999+git%"
and there is only one xserver-xorg with PV="1.6.999+gitr${SRCPV}" in my
tree.

--
uin:136542059 jid:Martin.Jansa@...
Jansa Martin sip:jamasip@...
JaMa

On Mon, 2009-09-14 at 00:43 +0200, Martin Jansa wrote:

+def isPreferredVersion(pe, pv, pr, preferred_e, preferred_v, preferred_r):
+ """
+ Check if the version pe,pv,pr is the preferred one.
+ If there is preferred version defined and ends with '%', then pv has to start with that version after removing the '%' in the end,
+ """

+ if (pv == preferred_v or (preferred_v != None and preferred_v.endswith('%') and pv.startswith(preferred_v[:len(preferred_v)-1]))):
+ if (pr == preferred_r or preferred_r == None):
+ if (pe == preferred_e or preferred_e == None):
+ return true
+ return false
+

I'm not totally comfortable that this patch is semantically well-formed.
If you start allowing wildcards then the idea of "the preferred version"
becomes somewhat ill-defined since, obviously, the wildcard might match
any number of files. I'm not quite sure what the problem is that you
are trying to solve, but my initial reaction is that (whatever the
problem is) it would probably be better solved another way.

p.

On Tue, Sep 15, 2009 at 09:11:40AM +0100, Phil Blundell wrote:

On Mon, 2009-09-14 at 00:43 +0200, Martin Jansa wrote:

+def isPreferredVersion(pe, pv, pr, preferred_e, preferred_v, preferred_r):
+ """
+ Check if the version pe,pv,pr is the preferred one.
+ If there is preferred version defined and ends with '%', then pv has to start with that version after removing the '%' in the end,
+ """

+ if (pv == preferred_v or (preferred_v != None and preferred_v.endswith('%') and pv.startswith(preferred_v[:len(preferred_v)-1]))):
+ if (pr == preferred_r or preferred_r == None):
+ if (pe == preferred_e or preferred_e == None):
+ return true
+ return false
+

I'm not totally comfortable that this patch is semantically well-formed.
If you start allowing wildcards then the idea of "the preferred version"
becomes somewhat ill-defined since, obviously, the wildcard might match
any number of files. I'm not quite sure what the problem is that you
are trying to solve, but my initial reaction is that (whatever the
problem is) it would probably be better solved another way.

p.

I wrote a bit more about my problem here:
http://article.gmane.org/gmane.comp.handhelds.openembedded/25986

Simply:
If I want to prefer bbfile with
PV=1.0+gitr${SRCPV}
then PV will change with every commit
so what PV should be in PREFERRED_VERSION_pkg?

With this patch I can put there "1.0+git%" which will match just this
one bbfile.

--
uin:136542059 jid:Martin.Jansa@...
Jansa Martin sip:jamasip@...
JaMa

On Tue, 2009-09-15 at 11:16 +0200, Martin Jansa wrote:

I wrote a bit more about my problem here:
http://article.gmane.org/gmane.comp.handhelds.openembedded/25986

Simply:
If I want to prefer bbfile with
PV=1.0+gitr${SRCPV}
then PV will change with every commit
so what PV should be in PREFERRED_VERSION_pkg?

With this patch I can put there "1.0+git%" which will match just this
one bbfile.

I would have thought you would be better off setting a positive
DEFAULT_PREFERENCE for your own DISTRO inside the bb file in question.
That doesn't require any bitbake changes and doesn't introduce any
semantically-murky extensions.

Your scheme of setting "1.0+git%" may work fine if there is just a
single git-based bb file in the repository but it would obviously break
down if a second one were ever to appear. That seems like an unhealthy
state of affairs.

p.

On Tue, Sep 15, 2009 at 11:31:51AM +0100, Phil Blundell wrote:

On Tue, 2009-09-15 at 11:16 +0200, Martin Jansa wrote:

I wrote a bit more about my problem here:
http://article.gmane.org/gmane.comp.handhelds.openembedded/25986

Simply:
If I want to prefer bbfile with
PV=1.0+gitr${SRCPV}
then PV will change with every commit
so what PV should be in PREFERRED_VERSION_pkg?

With this patch I can put there "1.0+git%" which will match just this
one bbfile.

I would have thought you would be better off setting a positive
DEFAULT_PREFERENCE for your own DISTRO inside the bb file in question.
That doesn't require any bitbake changes and doesn't introduce any
semantically-murky extensions.

Your scheme of setting "1.0+git%" may work fine if there is just a
single git-based bb file in the repository but it would obviously break
down if a second one were ever to appear. That seems like an unhealthy
state of affairs.

p.

Ok, but then you can say, that the same problem is when there is two or
more packages with PV = "1.0".

You can have as many git-based bb files as long as they have different
PV prefix like 1.0+git% and then 1.1+git% or 2.0+git.

Why would you have more bbffiles with the same PN and all git-based with
PV = "1.0+gitr${SRCPV}" ?

Setting PREFERRED_VERSION_pkg at least close enough to match
"1.0+gitr${SRCPV}" seems better for me than not setting preferred at
all and rely on DEFAULT_PREFERENCE.

BTW: in shr there is one distribution "shr" with -testing and -unstable
variants, main difference is which files with srcrevs and preferred
versions are included during build, how to set DEFAULT_PREFERENCE in
bbfile for this case (-testing wants some relased version, -unstable
using AUTOREV on _git version)?

Regards

--
uin:136542059 jid:Martin.Jansa@...
Jansa Martin sip:jamasip@...
JaMa

On Tue, 2009-09-15 at 09:11 +0100, Phil Blundell wrote:

On Mon, 2009-09-14 at 00:43 +0200, Martin Jansa wrote:

+def isPreferredVersion(pe, pv, pr, preferred_e, preferred_v, preferred_r):
+ """
+ Check if the version pe,pv,pr is the preferred one.
+ If there is preferred version defined and ends with '%', then pv has to start with that version after removing the '%' in the end,
+ """

+ if (pv == preferred_v or (preferred_v != None and preferred_v.endswith('%') and pv.startswith(preferred_v[:len(preferred_v)-1]))):
+ if (pr == preferred_r or preferred_r == None):
+ if (pe == preferred_e or preferred_e == None):
+ return true
+ return false
+

I'm not totally comfortable that this patch is semantically well-formed.
If you start allowing wildcards then the idea of "the preferred version"
becomes somewhat ill-defined since, obviously, the wildcard might match
any number of files. I'm not quite sure what the problem is that you
are trying to solve, but my initial reaction is that (whatever the
problem is) it would probably be better solved another way.

I can see what this patch is driving at as I've been in this position
before and its ugly. By default you usually want git recipes to have the
lowest preference. You then usually want to have some "bleeding" distro
config which changes those recipes to the default and selects them.
Raising their default preference and overriding any other
PREFERRED_VERSION is harder than it looks requiring two lines of config
whereas with the patch it allows this operation to be made easier and
works more as you'd expect.

On the other hand I do have doubts about the strange syntax which
doesn't match anything else we use and is a valid concern. The multiple
git recipes issue is an interesting one and I don't know how that would
work or whether we'd see it in practise.

That point in the code is a hotpoint and we need something low overhead
(i.e. not regexp) which this patch is.

I am seriously tempted to add something though as there is a missing
chunk of control here...

Cheers,

Richard

On Tue, 2009-09-15 at 13:56 +0200, Martin Jansa wrote:

Ok, but then you can say, that the same problem is when there is two or
more packages with PV = "1.0".

You can have as many git-based bb files as long as they have different
PV prefix like 1.0+git% and then 1.1+git% or 2.0+git.

Why would you have more bbffiles with the same PN and all git-based with
PV = "1.0+gitr${SRCPV}" ?

Well, er, because the git tree contains multiple revisions. There's no
reason why I mightn't want to package git revision
9324048f648da3b5ac3e507ab5fcc1bb8a3721c9 if that one worked particularly
well for me, whereas someone else might prefer to package revision
aea9acb329d715db851c1bed8506c3d0f9b42ae1. If those two versions are
different enough to require recipe differences then you would indeed end
up with two different .bb files.

Given that the primary use of floating git versions is for upstream
projects that don't release often (or at all), it doesn't seem like
relying on the released version number to disambiguate these different
git checkouts is going to get you very far.

Setting PREFERRED_VERSION_pkg at least close enough to match
"1.0+gitr${SRCPV}" seems better for me than not setting preferred at
all and rely on DEFAULT_PREFERENCE.

I agree that setting PREFERRED_VERSION would be somewhat neater, but
only if there was a way to obtain the actual floating version that is
going to be used. I don't think wildcards are an appropriate way to
solve that problem, and definitely not if the implementation is going to
end up as fragile as this one seems to be.

BTW: in shr there is one distribution "shr" with -testing and -unstable
variants, main difference is which files with srcrevs and preferred
versions are included during build, how to set DEFAULT_PREFERENCE in
bbfile for this case (-testing wants some relased version, -unstable
using AUTOREV on _git version)?

If the -testing distribution is selecting a fixed version then this will
override any default preference that might be set on the floating
recipe. So I don't think there is any problem here.

p.