Re: [bitbake-devel] [RFC PATCH 00/15] Make mirror replacement syntax explicit

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

On Wed, 2025-02-05 at 08:15 +0100, Stefan Herbrechtsmeier via lists.openembedded.org wrote:
> The mirror replacement syntax contains many implicit transformations.
> The path of the URI always contains the base name of the downloaded
> filename. This makes it impossible to rename or remove the base name of
> the original path. It prevents upstream mirror for SRC_URIS with a
> downloadfilename parameter. The base name of the downloaded filename
> makes it impossible to use the download mirror for SRC_URIs with
> subfolders in the downloadfilename parameter. Altogether the implicit
> transformation complicates the understanding of the replacements.
> 
> This series adds an additional replacement named DOWNLOADFILENAME. This
> replacement contains the relative filename of the downloaded file or
> mirror archive for git and hg. This allows the user to explicitly define
> the behavior. The usage is equivalent to the PATH replacement for the
> sstate mirror from file to https scheme.
> 
> git://.*/.*  http://downloads.yoctoproject.org/mirror/sources/DOWNLOADFILENAME
> https?://.*/.*  http://downloads.yoctoproject.org/mirror/sources/DOWNLOADFILENAME
> file://.*  https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH
> 
> Without a replacement variable the mirror will use the same base name as
> the origin SRC_URI. This allows the usage of private package manager
> registry together with a downloadfilename parameter or the rename of the
> base name.
> 
> https://registry.npmjs.org/  https://example.com/npm/registry/
> https://example.com/example/1.0.0.tgz  https://example.com/example/example-1.0.0.tgz
> 
> The series adds heuristics to keep a backward compatibility to common
> styles. Because of the ambiguity of the old style, it is advisable to
> remove this compatibility sooner or later to avoid unexpected behavior.

Thanks for the patches, these look interesting with some good
improvements in there. A lot of the series looks like cleanups and
those look like good fixes to have. It may make sense to split this
series into two, the cleanups/fixes and the behaviour changes.

I'm not entirely "sold" on the naming of DOWNLOADFILENAME. You have to
think about this from the perspective of someone writing a MIRROR or
PREMIRROR entry - would they understand what that means vs some of the
other names?

I'm also a bit nervous about breaking compatibility with the older
syntaxes. It is unclear to me how or when  we'd detect/deprecate older
formats. I do agree we probably do need to remove some support for some
syntax and move to something new though as what we have is turning into
some kind of nightmare. FWIW this is really old code that in many ways
predates my involvement so probably 20+ years old.

I'll continue to give this some thought. If you could confirm which
patches are "cleanup" that would help though, we can see if we can get
those in a bit faster.

Cheers,

Richard