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

[Andre McCurdy]

On Fri, Jun 15, 2018 at 2:58 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> 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?

OK. I was assuming that anyone using master oe-core would be using
master bitbake too. Delaying the change going into oe-core is
certainly safer though.