[oe] [PATCH] Allow % as wildcard in the end of PREFERRED_VERSION_pkg

Phil Blundell philb at gnu.org
Tue Sep 15 13:38:07 UTC 2009


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.






More information about the Openembedded-devel mailing list