#861 Give download tarball option for commits
Closed: Fixed 3 years ago Opened 6 years ago by akurtakov.

CGit has this nice feature when viewing commit details to have download option for the whole repo at this commit. See attached screenshot.
Screenshot_from_2016-03-24_13-33-00.png


Does Pagure have an "Download tarball" option at all? I can't find any button like that on the website

@qazwsxedc Not for the moment indeed :)

I would like this too, but I suggest expanding the feature to support downloading tarballs of arbitrary git refs (which would include commit hashes, tags, and branch names).

If this is to be implemented, maybe it would be worth putting some more
thoughts on durable stability of the archives, ideally with a perspective
of tarballs being stable for 5+ years. This is where GH failed:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UDZ2WKMTOE6J2M4K7PF5OWSSC4BAX2SH/

I would like to see this aswell.

I'm missing this more and more as there are now useful upstream sources stored in pagure and I find myself wanting to package snapshots of them.

I also note that if this gets added, a section in the relevant packaging guidelines at http://fedoraproject.org/wiki/Packaging:SourceURL would be great, and I'll happily write it. If the implementation managed to avoid requiring the gymnastics that the other hosting services require to get a proper tarball then that would be even better.

Please allow direct download of project code in archive form for releases, versions and tags, so pagure-hosted projects can be easily packaged in Fedora using %forgemeta like with GitHub or GitLab, as requested by Matthew Miller here: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/XJQG5V7SVTMDFNIQNJ2W5UM4C6JCWDWU/

See also:
- https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation
- https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/5K4CED5IBVTS567QJEYGUWLPBFYONDLN/
- https://pagure.io/packaging-committee/issue/719
- https://bugzilla.redhat.com/show_bug.cgi?id=1523779

Ideally:
- archives are compressed with tar.xz
- archives contain a topdir matching their name
- archives do not contain .git and other git-specific metadata
- the archive modification time matches the corresponding commit time
- archive urls end with /archivename.tar.xz to make rpm happy
- release archives are named project-release (and project is the same as in https://pagure.io/project/)
- tag archives are named project-tag
- commit archives are named project-commit

Pagure already allows manual release uploading but tagging a commit as a release commit should be sufficient to generate the corresponding release archive automatically without manual upload (as on GitLab)

Ideally:
- archives are compressed with tar.xz

Actually, I'd suggest that they don't get compressed with tar.xz. I'd suggest sticking with tar.gz and tar.bz2 as the former is light on resources to compress and the latter is great for high compression.

I've discovered from time to time that xz compressed tarballs can be somewhat screwy to deal with, which might explain why both GitHub and GitLab don't generate them.

Hi Neal,

Care to explain why you mean by screwy? I never had problems with tar.xz, they compress better than tar.bz2, and they are well supported even on non Linux OSes nowadays

OTOH I had no end of problems spectooling tar.gzs from github, to the point I systematically check archive integrity now before launching mock. The problems seem to happen mostly on big projects, so anything that compresses better would probably avoid hitting them

Care to explain why you mean by screwy? I never had problems with tar.xz, they compress better than tar.bz2, and they are well supported even on non Linux OSes nowadays

The main problem is that the compression is unstable. Depending on the release of xz being used, the archives will look different even with the same settings.

The other big problem with xz is that it has a larger memory footprint than gzip and bzip2 for making archives at relatively equitable compression levels.

Any chance we could have this anytime soon? At least with gzip and zstd compressed archives (both are fast and offer decent compression ratios).

Scoping this for 5.2 initially, potentially 5.3 if we need 5.2 before it's done :)

Metadata Update from @pingou:
- Issue set to the milestone: 5.2
- Issue tagged with: RFE

3 years ago

Metadata Update from @pingou:
- Issue assigned to pingou

3 years ago

Login to comment on this ticket.

Metadata
Attachments 1
Related Pull Requests
  • #4107 Merged 3 years ago