Other problems I encounter with Github‐generated tarballs: most projects that use Autoconf don’t keep the generated configure script in the repository, so the Github tarball has a build dependency on autoconf (as opposed to tarballs generated with “make dist”).

Also, many people don’t realize that Github tarballs don’t contain submodules. This is a big hassle when upstreams don’t adequately test their releases.

Providing a working tarball is becoming less and less common due to Github’s (and other sites’) UI. Taking the steps in the article is very helpful to packagers all over, but the above factors can be a problem for upstreams who aren’t aware of the problems.

It's not github's fault that RPM's tooling is stuck in the 90s, to be honest. makepkg and others support renaming tarballs during download to cover this use case.

I don't disagree, but it just feels off to tell a packaging tool to rename a tarball because the default name is not verbose enough to even identify the tarball.

But even so it is designed to be likely to get accidental collisions.

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.

It'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#...

Specify

  https://github.com/username/repo/archive/v0.1.1/foo-0.1.1.tar.gz

for the URL.

My god, that's the solution to my problem. Thank you very much. I did not realize that url was available.

I 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.