(could you bottom post rather than top post, it just makes it easier
for me to refer back to your points.)
On Sat, 16 Jan 2010, Christopher Larson wrote:
> You seem to be confused, perhaps I can make it clearer. Fetchers
> aren't limited to tarballs, and every file:// used for a patch in
> nearly every recipe is using the local fetcher.
ok, i think i phrased that badly. the *standard* strategy for
"fetch"ing package source is what i call the net-based fetch
implementations, such as wget (ftp/http/https), cvs, svn, git and so
on (all those fetchers in lib/bb/fetch/). in a perfect world, all
pristine package sources would exist somewhere out on the net, and
would be fetchable in one form or another.
*locally*, though, the local fetcher is typically used to refer to
content that's part of the OE checkout -- patch files, config files
and so on. philosophically, it makes no sense to fetch package
sources using the local fetcher since that implies that those sources
are actually part of the OE repository.
however, as i noted, there are a small number of tarballs in the OE
checkout:
$ find . -name *tar.gz
./recipes/firmwares/marvell-gspi-fw/9.70.3-p37.tar.gz
./recipes/firmwares/marvell-sdio-fw/9.70.3-p37.tar.gz
./recipes/x-load/files/x-loader-03.00.00.01.tar.gz
./recipes/sgalib/sgalib-0.1.0/sgalib-0.1.0.tar.gz
./recipes/qpealarmclock/qpealarmclockapplet-1.0.9/missing-files.tar.gz
./recipes/zaurus-utils/files/gnu-tar.gz
$
i have to assume the the *only* reason tarballs are included in the
OE checkout is that they're unavailable for downloading for one reason
or another, but i consider those to be really special and unusual
cases. put another way, the overwhelming reason to do local fetches
is to fetch, in a sense, package "add-ons" like patches, config info
and so on, no?
in short, i'm not sure i would even call the local fetcher a
"fetcher". it's simply a way to refer to local content to be somehow
applied to package source.
does that make more sense?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev
