All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Denys Dmytriyenko" <denis@denix.org>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] standard for names for local source mirror tarballs for git-based recipes?
Date: Wed, 21 Apr 2021 17:45:34 -0400	[thread overview]
Message-ID: <20210421214534.GT15937@denix.org> (raw)
In-Reply-To: <373df555-e7c2-f0b4-11c5-575d209391ea@crashcourse.ca>

On Wed, Apr 21, 2021 at 07:44:45AM -0400, Robert P. J. Day wrote:
> 
>   based on my recommendation, colleague created a local source mirror
> to start collecting tarballs so as to minimize amount of downloading
> for various builds. names of tarballs that correspond to fixed
> (versioned) tarballs was fairly obvious, but he got stuck trying to
> local source mirror a tarball for googletest (from meta-oe), which
> contains (among other things):
> 
>   googletest_git.bb
>   ...
>   PV = "1.10.0"
>   S = "${WORKDIR}/git"
>   SRCREV = "703bd9caab50b139428cea1aaff9974ebee5742e"
>   SRC_URI = "git://github.com/google/googletest.git"
> 
> he wasn't sure what name the tarball should have in order to be
> recognized in the local source mirror. i didn't have the answer off
> the top of my head, but since for years i've enhanced all my builds
> with a site.conf file containing:
> 
>   SOURCE_MIRROR_URL ?= "file:///home/rpjday/oe/dist/tarballs/"
>   INHERIT += "own-mirrors"
>   BB_GENERATE_MIRROR_TARBALLS = "1"
> 
> i just added googletest to a random build to see what i'd get, and
> got:
> 
>   git2_github.com.google.googletest.git.tar.gz
> 
> i guess i'd never paid close attention to the name generation for such
> things, but i'm *assuming* that the name generation by the appropriate
> fetcher code simply encodes everything there is to know about the
> source so that the appropriate tarball is recognized as the local
> source mirror version for that recipe. is that about right?
> 
>   second question: clearly, the simple name of that tarball doesn't
> encode the PV or SRCREV values, so what happens if the base recipe
> suddenly bumps PV up to 1.11.0? i'm sure the answer is obvious, i've
> just never thought about it.

The tarball with the previous clonedir will be unpacked and bitbake will check 
if required SRCREV exists in there. If not, it will try to update the clonedir 
from upstream.

-- 
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

  reply	other threads:[~2021-04-21 21:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 11:44 standard for names for local source mirror tarballs for git-based recipes? Robert P. J. Day
2021-04-21 21:45 ` Denys Dmytriyenko [this message]
2021-04-22  8:43   ` [OE-core] " Robert P. J. Day

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=20210421214534.GT15937@denix.org \
    --to=denis@denix.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=rpjday@crashcourse.ca \
    /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.