#1278 Source renamed when using Commit Revision URL
Closed: nothingtodo 9 months ago by tibbs. Opened a year ago by mattia.

In the Commit Revision URL example for Github, the example URL is

https://github.com/OWNER/PROJECT/archive/%{commit}/%{name}-%{shortcommit}.tar.gz

However, upon download github renames the tarball using the full commit hash, i.e. %{name}-%{commit}.tar.gz
This is quite confusing, I think, especially for newcomers. The workaround is explained in the Troublesome URLs section below, but it is not straightforward.
Shell we change the URL example to

https://github.com/OWNER/PROJECT/archive/%{commit}/%{name}-%{shortcommit}.tar.gz#/%{name}-%{commit}.tar.gz

Also the following seems to work and is slightly shorter:

https://github.com/OWNER/PROJECT/archive/%{commit}tar.gz#/%{name}-%{commit}.tar.gz

BTW to be precise it should be:

https://github.com/OWNER/PROJECT/archive/%{commit}tar.gz#/PROJECT-%{commit}.tar.gz

(if PROJECT != %{name})


Huh, are you sure? This would indicate that GitHub changed the behavior of these download links ...

...but that's true only with a browser... wget doesn't show the rename behavior... I should have thought about that before.

Yeah, opening those URLs with a browser is going to give you different file names than fetching them with cURL / wget / spectool ... if those still work correctly then I'm inclined to say "NOTABUG", not sure why browsers behave differently :/

Yeah, opening those URLs with a browser is going to give you different file names than fetching them with cURL / wget / spectool ... if those still work correctly then I'm inclined to say "NOTABUG", not sure why browsers behave differently :/

This happens because browsers set the filename based on this header:

content-disposition: attachment; filename=Celestia-7cf93d9a8cb193ee11aec0f0f0cd86be022190be.tar.gz

I don't think there's anything to do here, since there is no issue when using the tools normally used to operating on spec files. And complicating the URLs seems undesirable. You would have to run something that parses the spec file to get at the true URL anyway, and at that point you might as well just run spectool -g.

Metadata Update from @tibbs:
- Issue close_status updated to: nothingtodo
- Issue status updated to: Closed (was: Open)

9 months ago

Login to comment on this ticket.

Metadata