[oe] AUTOREV and SRCPV
pieterg
pieterg at gmx.com
Thu Jun 3 08:02:31 UTC 2010
On Thursday 03 June 2010 09:37:17 Martin Jansa wrote:
> On Thu, Jun 03, 2010 at 09:15:56AM +0200, pieterg wrote:
> > On Thursday 03 June 2010 06:35:05 Martin Jansa wrote:
<snip>
> > > If you use bitbake-1.10 it will do it just once for git revision (it
> > > will cache the result of "git list-rev | wc -l" which is used by
> > > BB_GIT_CLONE_FOR_SRCREV.
> >
> > Probably, but I don't get that far, bitbake quits at the end, with
> > several parsing errors (problems with git repositories which I have no
> > control over, and which I don't even want anything to do with)
>
> I'm aware of this problem and was discussed in that thread half a year
> ago, pity that you didn't join the discussion back then :/. But FYI all
> recipes with SRCPV builds OK here (without BB_GIT_CLONE_FOR_SRCREV but
> git servers are accessible for me).
Yes, I know I'm too late now ;)
We were way behind with our oe merges back then, and only recently I started
to get back uptodate again. So I didn't even realise the impact it would
have for us untill now.
> > There are two sorts of people, those with BB_GIT_CLONE_FOR_SRCREV, and
> > those without.
> > (or in my case, this is controlled by the distro, an 'unstable',
> > or 'release').
> > As long as the versioning is consistent for each group of people (or in
> > my case, each distro), I don't need the versioning to stay consistent
> > when toggling BB_GIT_CLONE_FOR_SRCREV.
>
> What about toggling AUTOREV and fixed revision? Which is imho more
> common change (ie when development gets slower and there is stable
> version in git and you don't need/want it AUTOREV). That's exacly the
> case when SRCPV is really handy.
But if you then decide to remove BB_GIT_CLONE_FOR_SRCREV again because you
no longer need it, and somebody starts a clean build, the LOCALCOUNT would
start at 0 again I guess.
So the versioning isn't consistent anyway when toggling
BB_GIT_CLONE_FOR_SRCREV.
> The other is when you change SRCREV in recipe without updating PV. Then
> SRCPV will give you newer PV which will upgrade resulting package on
> target.
Yes, but only if you stick to the same buildserver, and as soon as the hdd
crashes for instance and you have to start with a clean build, everybody is
in trouble.
So personally, I would never even want to use SRCPV, unless it's for
AUTOREV.
Would it be an idea to be able to only have BB_GIT_CLONE_FOR_SRCREV for
those packages which have SRCREV = ${AUTOREV}?
Rgds, Pieter
More information about the Openembedded-devel
mailing list