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.

-- Chris Larson

On Jan 16, 2010, at 3:05 AM, "Robert P. J. Day"  
<[email protected]> wrote:

>
>  i'm about to reorg the bitbake manual fetcher chapter, so i have
> some questions.  currently, the list of fetcher types in the manual is
> clearly incomplete.  if i peruse the python files in lib/bb/fetch, the
> currently supported types appear to be:
>
>  * local
>  * bzr
>  * cvs
>  * git
>  * hg
>  * osc
>  * perforce
>  * ssh
>  * svk
>  * svn
>  * wget (actually ftp/http/https)
>
>  so, the questions:
>
> 1) are all of the above actually functional?  all that are should be
> added to the manual and i can do that.  and even if i don't officially
> document each type, i can at least add a section that reads
> "documentation coming soon" or something like that so readers at least
> know that such a Fetcher exists.
>
> 2) the page on the local file fetcher claims that its behaviour
> depends on OVERRIDES.  however, if i grep local.py, there is no
> mention of any conditional checks on that variable.  if i check which
> of the fetcher types refers to that variable, i get:
>
> $ grep -lw OVERRIDES *.py
> cvs.py
> perforce.py
> wget.py
> $
>
>  perhaps i just don't understand python enough yet, but if a fetcher
> implementation doesn't refer to or test that variable in any way, how
> can it depend on its behaviour?
>
> 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
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev

Reply via email to