On Sat, 16 Jan 2010, Christopher Larson wrote:
> All existing fetchers should be considered supported today, so of
> any are broken, those are bugs. The local fetcher today is
> essentially a no-op, as the real work about grabbing the correct
> version of the file is in do_unpack. I'd suggest just removing the
> bit about local using overrides entirely.
pardon the interruption again but, out of curiosity, i did a "find"
on the OE dev checkout to see what existed in the checkout in terms of
tarballs and:
$ 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 looked at sgalib more closely and here's the relevant line from
the .bb file:
SRC_URI = "file://sgalib-${PV}.tar.gz"
so this is a SRC_URI that clearly invokes the local fetcher and, sure
enough, the sgalib tarball is in the relative subdirectory
recipes/sgalib/sgalib-0.1.0/.
clearly, this sort of thing doesn't happen often, so i'm guessing a
local fetch of a tarball is used only when there's nowhere else to
fetch the package from so it's been hardcoded into the OE repository.
is that what's happening here?
what other reasons would there be to commit actual tarballs into the
OE repo, other than that they don't exist anywhere on the net anymore?
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
