Re: [bitbake-devel][RFC][PATCH] bitbake: fetch2: correct PREMIRROR URI

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Sun, 2021-08-29 at 23:56 -0400, Scott Weaver wrote:
> When downloadfilename is defined in a recipe's SRC_URI and a PREMIRROR is also
> defined for that URI, the downloadfilename is appended to the mirror URI and it
> should not be appended.
> 
> Three new fetch bitbake-selftest tests were added to test downloadfilename
> scenarios.
> 
> [YOCTO #13039]
> 
> Signed-off-by: Scott Weaver <weaverjs@gmail.com>
> ---
> 
> This fix is for BZ13039.
> 
> downloadfilename is defined as "the filename used when storing the downloaded
> file" under the definition of SRC_URI [1].
> This definition appears to be echoed in 44.3.2 where it says downloadfilename
> "allows the name of the downloaded file to be specified" [2]. Although, the
> second definition isn't as clear and could be interpreted to mean that the
> name of the file to be downloaded can be specified. Which, if intentional,
> would not match the first definition.
> 
> I believe that the first definition is the correct definition of
> downloadfilename.
> 
> I've added three new tests to bitbake-selftest's fetch testsuite.
> 
> Executed against the master branch, the following new tests fail (see patch):
> 
> test_fetch_premirror_specify_downloadfilename_regex_uri() fails because
> the fetcher attempts to download the downloadfilename.
> 
> test_fetch_premirror_specify_downloadfilename_specific_uri() was added
> to address BZ13039 and is expected to fail.
> 
> These tests pass when executed with this patch applied.
> 
> However, this change breaks the test that I have commented out in the patch
> which is executed by MirrorUriTest.test_urireplace.
> I don't believe this is a valid test because a mirror is normally the location
> where an artifact can be found and should not specify the filename itself.

I'm afraid I have to disagree on that.

If someone specifies a full URL in a mirror definition, they expect it to map to
that specific url. We need to find a way to fix your corner case but keep
complete mappings working.

Cheers,

Richard