[OE-core] [PATCH] bitbake.conf: drop FETCHCMD, GITDIR, etc fetcher over-rides

[Richard Purdie]

On Fri, 2018-06-15 at 11:43 -0700, Andre McCurdy wrote:
> Following recent updates to the bitbake, the fetchers should now all
> contain safe and correct defaults for the subdirectory within DL_DIR
> to use and the base fetch command to run. It's no longer necessary
> for bitbake.conf to specify these values.
> 
> This is cleanup which was originally proposed in 2012:
> 
>   http://lists.openembedded.org/pipermail/openembedded-core/2012-July
> /064224.html
> 
> Signed-off-by: Andre McCurdy <armccurdy at gmail.com>
> ---
>  meta/conf/bitbake.conf | 12 ------------
>  1 file changed, 12 deletions(-)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 3b2ef9f..8588684 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -349,12 +349,6 @@ CACHE = "${TMPDIR}/cache${@['', '/' +
> str(d.getVar('MACHINE'))][bool(d.getVar('M
>  # The persistent cache should be shared by all builds
>  PERSISTENT_DIR = "${TOPDIR}/cache"
>  LOG_DIR = "${TMPDIR}/log"
> -CO_DIR = "${DL_DIR}"
> -CVSDIR = "${CO_DIR}/cvs"
> -SVNDIR = "${CO_DIR}/svn"
> -GITDIR = "${CO_DIR}/git2"
> -BZRDIR = "${CO_DIR}/bzr"
> -HGDIR = "${CO_DIR}/hg"
>  
>  STAMPS_DIR ?= "${TMPDIR}/stamps"
>  STAMP =
> "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
> @@ -661,12 +655,6 @@ SRC_URI[vardepsexclude] += "\
>  #  export DEBIAN_MIRROR = "http://ftp.de.debian.org/debian/pool"
>  #     into your local.conf
>  
> -FETCHCMD_svn = "/usr/bin/env svn --non-interactive --trust-server-
> cert"
> -FETCHCMD_cvs = "/usr/bin/env cvs"
> -FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --passive-ftp --no-
> check-certificate"
> -FETCHCMD_bzr = "/usr/bin/env bzr"
> -FETCHCMD_hg = "/usr/bin/env hg"
> -
>  SRCDATE = "${DATE}"
>  SRCREV ??= "INVALID"
>  AUTOREV = "${@bb.fetch2.get_autorev(d)}"

To make this work, we need to force everyone to upgrade their bitbake
beyond the point where these have been added to the fetcher.

We could do that with the minimum bitbake version but I'm tempted to
hold this for a but until we have another more pressing reason to bump
the minimum bitbake version and then do this at the same time?

Cheers,

Richard