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? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto