Re: AUTOREV and SRCPV

[pieterg <pieterg@gmx.com>]

On Thursday 03 June 2010 06:35:05 Martin Jansa wrote:
> On Wed, Jun 02, 2010 at 11:51:37PM +0200, pieterg wrote:
> > I have only a handful of (git) packages for which I need to use
> > AUTOREV, but when I define
> >
> > BB_GIT_CLONE_FOR_SRCREV = "1"
> > BB_LOCALCOUNT_OVERRIDE = ""
> >
> > the sideeffect is that hundreds of other packages (which I don't need)
> > are suddenly having their repositories cloned as well, when their bb
> > files are parsed. Even though these packages are not using AUTOREV,
> > they have fixed SRCREV's (either in their bb files, or in my distro).
> >
> > This is obviously taking a long time, consuming a lot of diskspace,
> > generating error messages for invalid git urls, and eventually bitbake
> > will fail because it encountered 'parsing errors' because of those
> > invalid git urls.
>
> 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 guess this is because all of these packages are using ${SRCPV} in
> > their PV, instead of ${SRCREV} (probably in order to find the correct
> > LOCALCOUNT for the gitrev).
> >
> > But argueing that people who don't use BB_GIT_CLONE_FOR_SRCREV will not
> > get these LOCALCOUNT's in their PV anyway, and people that do use
> > BB_GIT_CLONE_FOR_SRCREV will use SRCREV = ${AUTOREV} for the packages
> > which they want to be automatically updated, so SRCREV would equal
> > SRCPV, wouldn't it make sense to just use ${SRCREV} instead of ${SRCPV}
> > in PV?
>
> No they won't be the same. They will have the same format
> git${LOCALCOUNT}+${HASH} as when AUTOREV+SRCREV is used.

My point is that I don't think they have to be the same.
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.

> in short: why do you insist on BB_GIT_CLONE_FOR_SRCREV? autoincremented
> LOCALCOUNT works good in most cases (as long as you keep cache dir), only
> case for which we introduced BB_LOCALCOUNT_OVERRIDE is for multiple
> builders sharing feed, but not cache directory.

And that's indeed what we have, many people are building the same distro, 
and they should end up with the exact same version (or LOCALCOUNT), and I 
don't think there is a way without clearing BB_LOCALCOUNT_OVERRIDE and 
setting BB_GIT_CLONE_FOR_SRCREV.

My point is, before the big SRCPV change, you only suffered for the 
carefully picked number of packages for which you wanted to use AUTOSRC.
But now, you suffer for hundreds of packages, which you might not even want 
to have anything to do with, packages which use fixed SRCREV's, so they 
shouldn't even need dynamically generated PVs.

For now, I've made this change in bitbake.conf, which pretty much reverts 
the behaviour to what it was before, so at least my build will complete
(don't mean to propose this patch of course, just as demonstration how I 
have to work around it at the moment)
Hopefully there is a better way to make AUTOREV work again for our 
situation.

From 30a9c042d65b32dc1d76a757f493659b556c6a62 Mon Sep 17 00:00:00 2001
From: pieterg <pieterg@users.sourceforge.net>
Date: Thu, 3 Jun 2010 00:23:51 +0200
Subject: [PATCH] bitbake.conf: work around AUTOREV problems

As long as many packages are using SRCPV in their PV,
we cannot use the current AUTOREV / SRCPV strategy
---
 conf/bitbake.conf |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 12a5522..1d2c123 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -576,8 +576,8 @@ UPDATECOMMAND_cvs = "/usr/bin/env 'PATH=${PATH}' 
cvs -d${CVSROOT} update -d -P $
 UPDATECOMMAND_svn = "/usr/bin/env svn update ${SVNCOOPTS}"
 SRCDATE = "${DATE}"
 SRCREV = "1"
-SRCPV = "${@bb.fetch.get_srcrev(d)}"
-AUTOREV = "${SRCPV}"
+SRCPV = "${SRCREV}"
+AUTOREV = "${@bb.fetch.get_srcrev(d)}"
 
 # For now disable autoincrement of revision counter in SRCPV, whoever wants 
it, should enable it in local.conf or distro config
 # Revision counter is incremented only locally (bad for multiple builders 
filling shared feeds), LOCALCOUNT can be used to maintain
-- 
1.6.5.rc1.44.ga1675