6 ms·

> 4. Go back to your "Releases" section and download the tarball mysoftware-0.4.tar.gz automatically generated by GitHub. If only. That's by far my biggest irk

by embik 10y ago

> 4. Go back to your "Releases" section and download the tarball mysoftware-0.4.tar.gz automatically generated by GitHub. If only. That's by far my biggest irk with GitHub releases because they only use the tag as name for the tarball (e.g. v0.4.tar.gz). Building RPM packages with those tarballs is a bit of a pain because RPM building tools expect all tarballs in one directory and you don't know which tarball belongs to which software. Maybe I'm just being ignorant here.

creshal 10y ago
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.
- embik 10y ago
  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.
  - justincormack 10y ago
    But even so it is designed to be likely to get accidental collisions.
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 ago
  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#SPEC_file_overview https://fedoraproject.org/wiki/How_to_create_an_RPM_package#...
  - Xylakant 10y ago
    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.
  - twr 10y ago
    Specify https://github.com/username/repo/archive/v0.1.1/foo-0.1.1.tar.gz for the URL.
    - embik 10y ago
      My god, that's the solution to my problem. Thank you very much. I did not realize that url was available.
anjbe 10y ago
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.

by embik 10y ago

creshal 10y ago

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.

embik 10y ago
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.
- justincormack 10y ago
  But even so it is designed to be likely to get accidental collisions.

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 ago
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#SPEC_file_overview https://fedoraproject.org/wiki/How_to_create_an_RPM_package#...
- Xylakant 10y ago
  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.
- twr 10y ago
  Specify https://github.com/username/repo/archive/v0.1.1/foo-0.1.1.tar.gz for the URL.
  - embik 10y ago
    My god, that's the solution to my problem. Thank you very much. I did not realize that url was available.

anjbe 10y ago

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.