On Tue, Oct 11, 2022 at 10:23 AM Stephan Lachnit<stephanlachnit@debian.org> wrote:
[...]On Sun, Oct 9, 2022 at 7:06 PM Volans <volans.ubuntu@gmail.com> wrote: [...]For releases I use something like (w/o signatures): ``` version=4 opts="searchmode=plain,\ filenamemangle=s%v?@ANY_VERSION@%@PACKAGE@-$1.tar.gz%" \ https://api.github.com/repos/<user>/<project>/releases?per_page=100
\ https://api.github.com/repos/[^/]+/[^/]+/tarball/v?@ANY_VERSION@
```
To add some additional burden I noticed that the archive downloaded
from the API [1] is different from the one downloaded from the
browser [2] because they have a different top-level directory name,
while the API one has: {OWNER}-{REPO}-{REF_SHA1}/ where REF_SHA1 is
the SHA1 of refs/tags/{TAG_NAME}, the browser one has:
{OWNER}-{VERSION}/ where, at least in my case, VERSION is the tag
name without the leading 'v'. For a tag name of 'v0.2.0' I get 'gjson-py-0.2.0.tar.gz' that extracted creates 'gjson-py-0.2.0/'
(note the lack of 'v' in the names).
Because of the two different directory structures, the tar.gz files
are different so any md5 or gpg signature verification made on one
would fail with the other, adding additional confusion or complexity.
For now I'll probably upload to the release page the signatures of
both files, but this is definitely suboptimal.
Riccardo
[1] https://api.github.com/repos/{OWNER}/{REPO}/tarball/{RELEASE}
[2]
https://codeload.github.com/{OWNER}/{REPO}/tar.gz/refs/tags/{RELEASE}
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:02:32 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |