On Sun, May 31, 2020 at 4:32 PM Zac Medico <zmed...@gentoo.org> wrote: > > On 5/31/20 1:24 PM, Ulrich Mueller wrote: > >>>>>> On Sun, 31 May 2020, Zac Medico wrote: > > > >> We've also got these other basename calls in fetch.py: > > > >>> diff --git a/lib/portage/package/ebuild/fetch.py > >>> b/lib/portage/package/ebuild/fetch.py > >>> index 28e7caf53..56b375d58 100644 > >>> --- a/lib/portage/package/ebuild/fetch.py > >>> +++ b/lib/portage/package/ebuild/fetch.py > >>> @@ -730,9 +730,9 @@ def fetch(myuris, mysettings, listonly=0, fetchonly=0, > >>> else: > >>> for myuri in myuris: > >>> if urlparse(myuri).scheme: > >>> - > >>> file_uri_tuples.append((os.path.basename(myuri), myuri)) > >>> + > >>> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), myuri)) > >>> else: > >>> - > >>> file_uri_tuples.append((os.path.basename(myuri), None)) > >>> + > >>> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), None)) > > > >> The case with no scheme is not a URI, so we need to decide whether > >> or not to unquote, and we should make _parse_uri_map behavior > >> consistent for this case. > > > > I think that this follows from PMS, section 8.2 [1]: > > > > | The following elements are recognised in at least one class of > > | specification. All elements must be surrounded on both sides by > > | whitespace, except at the start and end of the string. > > | > > | [...] > > | - A URI, in the form proto://host/path. Permitted in SRC_URI and > > | HOMEPAGE. In EAPIs listed in table 8.4 as supporting SRC_URI arrows, > > | may optionally be followed by whitespace, then ->, then whitespace, > > | then a simple filename when in SRC_URI. For SRC_URI behaviour, see > > | section 8.2.10. > > | - A flat filename. Permitted in SRC_URI. > > > > So if it isn't an URI then it is a "flat filename" which IMHO is to be > > interpreted literally without any unquoting. > > > > Ulrich > > > > [1] https://projects.gentoo.org/pms/7/pms.html#x1-690008.2 > > > > This interpretation sounds good to me.
Agreed.
