From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: AUTOREV and SRCPV
Date: Thu, 3 Jun 2010 06:35:05 +0200 [thread overview]
Message-ID: <20100603043505.GJ16035@jama> (raw)
In-Reply-To: <201006022351.38129.pieterg@gmx.com>
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.
> 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.
Check "[oe] SRCPV migration - How SRCPV works!" thread for more info
http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg01607.html
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.
Regards,
--
uin:136542059 jid:Martin.Jansa@gmail.com
Jansa Martin sip:jamasip@voip.wengo.fr
JaMa
next prev parent reply other threads:[~2010-06-03 4:39 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-02 21:51 AUTOREV and SRCPV pieterg
2010-06-03 4:35 ` Martin Jansa [this message]
2010-06-03 7:15 ` pieterg
2010-06-03 7:37 ` Martin Jansa
2010-06-03 8:02 ` pieterg
2010-06-03 8:27 ` Martin Jansa
2010-06-03 8:44 ` pieterg
2010-06-03 9:22 ` pieterg
2010-06-03 8:13 ` Phil Blundell
2010-06-03 8:30 ` Martin Jansa
2010-06-03 8:37 ` Phil Blundell
2010-06-03 8:46 ` Martin Jansa
2010-06-03 8:55 ` Phil Blundell
2010-06-03 16:35 ` Phil Blundell
2010-06-04 8:24 ` pieterg
2010-06-04 8:30 ` Phil Blundell
2010-06-04 8:44 ` pieterg
2010-06-04 11:03 ` Phil Blundell
2010-06-05 10:36 ` pieterg
2010-06-06 21:00 ` Phil Blundell
2010-06-07 0:13 ` Khem Raj
2010-06-08 10:09 ` Phil Blundell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100603043505.GJ16035@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.