All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: yocto@yoctoproject.org
Subject: Re: how to set up PREMIRRORS_prepend to avoid constant git clones?
Date: Sat, 10 Mar 2012 03:52:34 -0700	[thread overview]
Message-ID: <4F5B3272.2010607@mlbassoc.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1203100523020.26289@oneiric>

On 2012-03-10 03:35, Robert P. J. Day wrote:
>
>    over the years, i've built up a sizable collection of source
> tarballs for use in various projects -- top-level directory called
> "~/dl", about 5G in size with lots and lots of .tgz and .bz2 files and
> so on, and i'd like to confirm the best way to take advantage of all
> that source whenever i configure and build a yocto project.
>
>    based on my reading, whenever i create a new project, i immediately
> add the following to the bottom of its local.conf file:
>
> PREMIRRORS_prepend = "\
> git://.*/.* file:///home/rpjday/dl/ \n \
> svn://.*/.* file:///home/rpjday/dl/ \n \
> cvs://.*/.* file:///home/rpjday/dl/ \n \
> ftp://.*/.* file:///home/rpjday/dl/ \n \
> http://.*/.* file:///home/rpjday/dl/ \n \
> https://.*/.* file:///home/rpjday/dl/ \n"
>
> and that certainly makes a massive difference -- whenever the fetching
> starts, matching tarballs will be located in my "dl" directory, and
> the project's downloads directory will be populated with symlinks to
> the actual tarballs, as in:
>
>    vala-0.14.2.tar.xz ->  /home/rpjday/dl/vala-0.14.2.tar.xz
>
> and after the download, i sneak a peek at whatever newer tarballs
> needed to be downloaded, and quietly copy them over to "dl" to avoid
> ever downloading them again, and that's worked well so far.  so, the
> questions:
>
> 1) does this sound reasonable?  i know about using DL_DIR and perhaps
> sharing that across projects, but i rather like the idea of an
> application-agnostic repository of straight tarballs and zip files
> that any build system is allowed to pilfer from (especially since i
> can make it read-only).
>
> 2) am i missing any fetch protocols from that list?
>
> 3) how do i set it up to avoid repeated git clones?
>
>    it seems that, while i can avoid fetching simple tarballs, i still
> end up doing the same "git clone" operations over and over.  am i just
> missing something obvious?

All you really need are these lines:
   SOURCE_MIRROR_URL ?= "file://${COREBASE}/sources/"
   INHERIT += "own-mirrors"
Adjust the SOURCE_MIRROR_URL to wherever you want the files.  I also always add
   BB_GENERATE_MIRROR_TARBALLS = "1"
This will let the fetcher make a git2_XXX tarball, once the repo has been cloned.

My understanding is that the git (and other SCM) fetcher works like this:
   * If there is a git2_XXX tar file in the DL_DIR (or mirror), unpack it
     into ${BUILD}/downloads/git2
   * Check to see if the desired ${SRCREV} is present.  If not, do a 'git pull'
     to update the local clone and then rebuild the git2_XXX tarball.
This way, you only have to clone once - just copy any generated tarballs back
to your source mirror.

Finally, if you set
   BB_NO_NETWORK = "1"
the build will fail if bitbake *ever* has to go to the network, i.e. not find
the desired files in the source mirror or DL_DIR.  This is a great way to insure
that you've got what you need locally.  I use this all the time to make sure I
have a fully populated local cache of sources.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


  reply	other threads:[~2012-03-10 10:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-10 10:35 how to set up PREMIRRORS_prepend to avoid constant git clones? Robert P. J. Day
2012-03-10 10:52 ` Gary Thomas [this message]
2012-03-10 10:58   ` Gary Thomas
2012-03-10 11:17   ` Robert P. J. Day
2012-03-10 11:23   ` Robert P. J. Day
2012-03-10 13:39   ` Robert P. J. Day
2012-03-10 14:55     ` Gary Thomas
2012-03-10 15:29       ` Robert P. J. Day
2012-03-10 15:34         ` Gary Thomas
2012-03-10 15:46           ` Robert P. J. Day
2012-03-10 15:51             ` Gary Thomas
2012-03-12  8:28               ` David Nyström

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=4F5B3272.2010607@mlbassoc.com \
    --to=gary@mlbassoc.com \
    --cc=yocto@yoctoproject.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.