3 ms·
Yes, you're being ignorant. Use '--content-disposition' with wget, or '--remote-name' in curl. The top level directory in the tarball corresponds to this name a
by jsizz 10y ago
Yes, you're being ignorant. Use '--content-disposition' with wget, or '--remote-name' in curl. The top level directory in the tarball corresponds to this name and everything works out as expected.
- embik 10y agoIt's not only the name of the tarball after downloading it. RPM SPEC files require me to pass a full URL to the tarball's upstream source[1]: > Source0: The full URL for the compressed archive containing the (original) pristine source code, as upstream released it. "Source" is synonymous with "Source0". If you give a full URL (and you should), its basename will be used when looking in the SOURCES directory. But the only URL that is available is <Project URL>/archive/v0.1.1.tar.gz. The SPEC file is therefore defining a file named v0.1.1.tar.gz although I downloaded my tarball as foo-0.1.1.tar.gz. The packaging process looks for v0.1.1.tar.gz, fails to find it in my SOURCES directory and aborts. I'm not blaming GitHub here in any way, I just wish I had a bit more flexibility for the tarball URL. Would be neat. [1] https://fedoraproject.org/wiki/How_to_create_an_RPM_package#SPEC_file_overview https://fedoraproject.org/wiki/How_to_create_an_RPM_package#...
- Xylakant 10y agoI recommend using some tooling that wraps the original rpm tooling, such as fpm or fpm-cookery. It does a fair job of covering up the worst warts.
- twr 10y agoSpecify https://github.com/username/repo/archive/v0.1.1/foo-0.1.1.tar.gz for the URL.
- embik 10y agoMy god, that's the solution to my problem. Thank you very much. I did not realize that url was available.