Re: Use AUTOREV and have revision/commit number in package name?

[Denys Dmytriyenko <denis@denix.org>]

On Thu, Aug 20, 2009 at 11:46:42AM +0200, Martin Jansa wrote:
> On Thu, Aug 20, 2009 at 05:01:36AM -0400, Denys Dmytriyenko wrote:
> > On Thu, Aug 20, 2009 at 10:34:58AM +0200, Koen Kooi wrote:
> > > On 20-08-09 09:10, Denys Dmytriyenko wrote:
> > >> On Thu, Aug 20, 2009 at 07:52:58AM +0200, Holger Hans Peter Freyther 
> > >> wrote:
> > >>> On Thursday 20 August 2009 05:28:02 Denys Dmytriyenko wrote:
> > >>>> Now, when SRCREV = "${AUTOREV}", AUTOREV gets resolved into a Python
> > >>>> function, which does the magic of fetching the latest snapshot from a
> > >>>> repository. But now if PV contains references to SRCREV, it breaks
> > >>>> (undesrandably), since SRCREV gets resolved in do_fetch and PV needs to 
> > >>>> be
> > >>>> resolved early on.
> > >>>>
> > >>>> Are there any standard ways to work around this limitation?
> > >>>
> > >>> Check the mailinglist archives... Openmoko has deployed a solution that 
> > >>> has
> > >>> fixed that about 1 1/2 years ago.
> > >>>
> > >>> Short answer:
> > >>> 	- Do not put SRCREV into PV, e.g. create a new var called SRCPV
> > >>> 	- Populate SRCPV with something based on the SRCREV..
> > >>
> > >> Ah, thanks! I was able to find your RFC message from last year on the 
> > >> Openmoko
> > >> mailing list:
> > >> http://markmail.org/message/v3s32gmxxqcaxpph
> > >>
> > >> I'll give it a try. Thanks.
> > >>
> > >> To be clear - it's not used in OE. While there is a single 
> > >> python-phoneutils
> > >> recipe, which references SRCPV, it is not being set anywhere, 
> > >> apparently...
> > >
> > > Take a look at 
> > > http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=xora/angstrom-srcpv 
> > > :)
> > 
> > Thanks! More specifically:
> > 
> > http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?h=xora/angstrom-srcpv&id=453a13c7a68087895f4048410aba1a519ec99897
> > 
> > Any ETA for the merge back to .dev? :)
> 
> Just out of my curiosity:
> 
> How are PREFERRED_VERSION_pkg supposed to work when I prefer pkg with
> autoreved revision.
> 
> bbfile will be named like pkg_git.bb
> inside will be PV="1.0.0+gitr${SRCPV}" and DEFAULT_PREFERENCE=-1
> 
> I would like to force using this _git version even when there will be
> pkg_1.1.0.bb with PV="1.1.0"
> 
> For fixed revision ie from sane-srcrevs i can bump PREFERRED_VERSION_pkg
> with every revision bump in sane-srcrevs, but it also suboptimal :/.
> 
> With autorev I cannot set PREFERRED_VERSION_pkg at all, if I understand
> it right, because I never know which string will be in ${SRCPV} and
> using just PREFERRED_VERSION_pkg="1.0.0+git" or "git" ends with
> "preferred version is not available". Setting PREFERRED_VERSION_pkg to
> "1.0.0+gitr${SRCPV}" is not expanded and ends with a bit confusing 
> bitbake exception about SRC_URI not referencing some SCM.
> 
> I've asked on IRC and they said that its common practise to remove
> PREFERRED_VERSION_pkg and adjust DEFAULT_PREFERENCE or blacklist all
> other versions (like that with PV="1.1.0").
> 
> Now I solved my problem with updating PV in recipies which weren't
> preferred by bitbake to latest version from all available (moved to
> PV="1.1.0+gitr${SRCPV}" when pkg_1.1.0.bb is commited and removed
> DEFAULT_PREFERENCE=-1.
> 
> Could it be solved better? Something like:
> 1) use .bb file with exact the same PV
> 2) use .bb file where PV starts with the same string as is in
> PREFERRED_VERSION_pkg if exact is not found and print warning.

Another approach, which may be even less elegant, would be to rename 
pkg_git.bb into pkg-git.bb, let it PROVIDE=pkg and select it by 
PREFERRED_PROVIDER_pkg=pkg-git, then its lower version wouldn't matter.

-- 
Denys