[Rpm-maint] [rpm-software-management/rpm] Odd handing of URLs containing a ? in Source*:/Patch*: lines (#1407)

[Michal Domonkos]

This is a known limitation in RPM, but there's a simple workaround, see below.

The way RPM [derives](https://github.com/rpm-software-management/rpm/blob/d601a7b7ae764b31ad74b2dceff1eafb5297147f/build/parsePreamble.c#L125) the target file name from a Patch/Source tag is by taking everything after the last `/` or `=` character, whichever comes last. That means, you can use a trick that involves appending a dummy URL fragment (`#/`) to force RPM to name the file differently, as follows:

```
Patch1: https://aur.archlinux.org/cgit/aur.git/plain/chromium-skia-harmony.patch?h=chromium-vaapi#/chromium-skia-harmony.patch
```

This is also documented in the Fedora wiki: https://fedoraproject.org/wiki/Packaging:SourceURL#Troublesome_URLs

The downside of this workaround is that you may need to repeat the original name of the file (unless you choose a different, perhaps shorter name), which makes the URL more verbose and more prone to error.

Now, as per [RFC 3986](https://tools.ietf.org/html/rfc3986#section-3.3), what follows after the `?` (query component) is not considered part of the *path*, so I agree it would make sense for RPM to strip that. However, if we made such a change now, I worry that some existing spec(s) out there would break, due to the assumption that `=` also acts as a file name separator:

```
Patch1: https://some/url/getpatch?name=foobar
```

This would store the file as `getpatch` as opposed to the previous `foobar`.

I wasn't able to trace down the exact rationale behind the `=` char in the spec parser, but I assume the idea was to allow such renames, similarly to `#/`.

For some real-world data, I grepped [all the ~21k Fedora spec files](https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz) and although there were quite a few that had a query component in one of the Patch/Source tags, I didn't find a single one that would rely on the `=` separator alone (there always was a `/` used to separate the target file name).

Still, we'd rather not introduce more "magic" to the URL parsing logic and risk a regression along the way, so I'll close this one. I'm hoping the URL fragment workaround will be sufficient for your use case! :)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1407#issuecomment-789040763
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20210302/be8d1b2d/attachment.html>