standard for names for local source mirror tarballs for git-based recipes?

standard for names for local source mirror tarballs for git-based recipes?

[Robert P. J. Day]

  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.

rday

Re: [OE-core] standard for names for local source mirror tarballs for git-based recipes?

[Denys Dmytriyenko]

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

Re: [OE-core] standard for names for local source mirror tarballs for git-based recipes?

[Robert P. J. Day]

On Wed, 21 Apr 2021, Denys Dmytriyenko wrote:

> 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.

  i feel silly for having asked this question since a little more
research clarified things nicely. *sigh*.

rday