Re: (PRE)MIRRORS doesn't work with https?$:// anymore Was: [PATCH] fetch2: Add new mirror syntax to simplify mirror specifications

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

On Tue, 2012-06-26 at 19:31 +0200, Martin Jansa wrote:
> On Thu, Jun 21, 2012 at 03:34:57PM +0100, Richard Purdie wrote:
> > When writing mirror specifications, the current regexp syntax can be awkward
> > and hard to get it to do what you want. For example, extracting the 'basename'
> > of a repository:
> > 
> > PREMIRRORS = "git://.*/([^/]+/)*([^/]*) git://somewhere.org/somedir/\\2;protocol=file"
> > 
> > can now become:
> > 
> > PREMIRRORS = "git://.*/.* git://somewhere.org/somedir/BASENAME;protocol=file"
> > 
> > which is much clearer. A MIRRORNAME substitution is also added which contains
> > an encoded form of both host and path. One of the problems with the existing
> > regexp syntax is you couldn't access HOST information from PATH and vice-versa
> > which is an issue this patch also addresses.
> 
> One of this fetch2 patches break https?:// in MIRRORS
> 
> It's used e.g in openembedded-core/meta/classes/mirrors.bbclass:
> https?$://.*/.* http://downloads.yoctoproject.org/mirror/sources/
> https?$://.*/.* http://sources.openembedded.org/
> 
> I've tested it with older bitbake in PREMIRRORS (to make log.do_fetch
> log shorter) on libcap (which doesn't exist on upstream URL).
> 
> PREMIRRORS_append () {
> cvs://.*/.* http://build.shr-project.org/sources/
> svn://.*/.* http://build.shr-project.org/sources/
> git://.*/.* http://build.shr-project.org/sources/
> hg://.*/.* http://build.shr-project.org/sources/
> bzr://.*/.* http://build.shr-project.org/sources/
> https?$://.*/.* http://build.shr-project.org/sources/
> }

This is almost certainly a result of:

http://git.openembedded.org/bitbake/commit/?id=604df1b25cf114e083f52917df2df64e01279c25

since I didn't believe anyone was using the regexp syntax in the base
url type. The bug I wanted to fix was where if you did:

https://.*/.* file:///some/path/

which seems reasonable enough, it would access:

files:///some/path/

which is clearly not what anyone would want.

I'm not sure what to do about fixing this...

Cheers,

Richard