For the package dist-git repo: https://src.fedoraproject.org/rpms/adobe-source-han-mono-fonts.git ...a completely shallow clone (no commit history) made with fedpkg has a size of 214MB: $ fedpkg -v clone -a --depth=1 adobe-source-han-mono-fonts Cloning https://src.fedoraproject.org/rpms/adobe-source-han-mono-fonts.git Running: git clone --depth 1 https://src.fedoraproject.org/rpms/adobe-source-han-mono-fonts.git --origin origin Cloning into 'adobe-source-han-mono-fonts'... remote: Enumerating objects: 18, done. remote: Counting objects: 100% (18/18), done. remote: Compressing objects: 100% (10/10), done. remote: Total 18 (delta 4), reused 8 (delta 4), pack-reused 0 Unpacking objects: 100% (18/18), 96.03 MiB | 11.93 MiB/s, done. $ du -sch adobe-source-han-mono-fonts 214M adobe-source-han-mono-fonts 214M total This is because the package source files, including the large font archive itself, are checked into the package repo instead of being stored in the lookaside cache. This is true even though the file that can be downloaded from the Source0 URL is identical to the checked-in copy. $ cd adobe-source-han-mono-fonts $ mv SourceHanMono.ttc SourceHanMono.bak $ spectool -g adobe-source-han-mono-fonts.spec Downloading: https://github.com/adobe-fonts/source-han-mono/releases/download/1.002/SourceHanMono.ttc 100% of 116.5 MiB |######################| Elapsed Time: 0:00:02 Time: 0:00:02 Downloaded: SourceHanMono.ttc Downloading: https://raw.githubusercontent.com/adobe-fonts/source-han-mono/1.002/LICENSE.md File '.../adobe-source-han-mono-fonts/LICENSE.md' already present. Downloading: https://raw.githubusercontent.com/adobe-fonts/source-han-mono/1.002/README.md File '.../adobe-source-han-mono-fonts/README.md' already present. $ sha256sum SourceHanMono.* 0c192448de90848f11eb8336876883a9a36dc65b8965e489600cfcc7a67358c1 SourceHanMono.bak 0c192448de90848f11eb8336876883a9a36dc65b8965e489600cfcc7a67358c1 SourceHanMono.ttc To avoid large downloads, upstream source files should not be committed to the package repo. Rather, they should be added to the builders' lookaside cache using `fedpkg new-sources`, which uploads the file to Koji and adds its name to the local `.gitignore` file so that it can't be checked in. To correct this (remove the source files from the Git history), a surgical rewrite of the repository history by a Fedora git administrator will be required. See https://pagure.io/releng/issue/7265 for when this was previously done, for the Blender package. An important point here is that it will NOT do any good to simply `git rm` the errant file -- it's still part of the commit history, so it'll still live in the `.git` directory and still cause large checkouts. Correcting this requires administrative rewrite of the repo's commit history, which can be done by releng but first has to be authorized by FeSCO because under normal circumstances rewriting package repo history is entirely prohibited. But I wanted to open this issue first, as a heads-up that the workflow for maintenance of the package will need to be adjusted. Source archives from upstream should never be committed to the package repo itself, only uploaded to the lookaside cache. See the Package Maintenance Guide section of the Packaging Guidelines, for some brief documentation regarding the lookaside cache (although the packaging docs' coverage of this topic could be better, IMHO): https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/#_upload_new_source_files_to_the_lookaside_cache Reproducible: Always
I've filed a releng ticket asking for their assistance in cleaning up the repo's history, that ticket is: https://pagure.io/releng/issue/12487 Traditionally it's been deemed necessary for releng to seek FESCO approval before performing any such cleanup, so there are a few steps to the whole process and it may take a bit of time.
I have submitted PR https://src.fedoraproject.org/rpms/adobe-source-han-mono-fonts/pull-request/3
Thanks. merged into dist-git.
Did nobody read my issue summary? "An important point here is that it will NOT do any good to simply `git rm` the errant file -- it's still part of the commit history, so it'll still live in the `.git` directory and still cause large checkouts. Correcting this requires administrative rewrite of the repo's commit history, which can be done by releng but first has to be authorized by FeSCO because under normal circumstances rewriting package repo history is entirely prohibited." This CANNOT be fixed by PR, the files are still in the Git history. If the PR changed the workflow to prevent this happening in the future, that's great, but it doesn't solve the underlying issue at all. Reopening, sorry.
There is nothing we can do here. If you think its problem for you then I request to report this to https://pagure.io/releng/issues. The releng is not under package maintainer control. I am closing this bug as there is really nothing a package maintainer can do here.
That's fair. Already reported as https://pagure.io/releng/issue/12487 so that end is covered.