Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#71400 - [linux] [linux-zen] Consider switching to tarball

Attached to Project: Arch Linux
Opened by Emil (xexaxo) - Tuesday, 29 June 2021, 19:28 GMT
Last edited by Eli Schwartz (eschwartz) - Tuesday, 29 June 2021, 19:47 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Tobias Powalowski (tpowa)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No



Please consider switching to tarball, while handling the extra patches either alongside the repo [1] or as separate (signed) tarball [2].

Currently we clone the github repo which results in ~3.2GiB of traffic, while the respective tarball it around 5MiB.
We are talking 3 orders of magnitude difference across the two.

This also translates to increased disk and execution, albeit to a smaller extend.



Additional info:
* package version(s)
linux 5.12.13.arch1-2
linux-zen 5.12.13.zen1-2
This task depends upon

Comment by Eli Schwartz (eschwartz) - Tuesday, 29 June 2021, 19:47 GMT
> while the respective tarball it around 5MiB

Hmm, the tarball should be around 100mb which is 1/30th the size of the git repo but still not exactly 5mb?
Comment by Michel Koss (MichelKoss1) - Tuesday, 29 June 2021, 20:26 GMT
Implementing shallow clone as option for cloning git repos would also help for this and others big repos.
Comment by John (graysky) - Tuesday, 29 June 2021, 20:33 GMT
I believe the shallow clone idea for makepkg was discussed in the past but denied. Have to search to confirm my memory.
Comment by Michel Koss (MichelKoss1) - Tuesday, 29 June 2021, 20:42 GMT
yeah but those big repos keep growing every day, month and year. I imagine there is some upper limit after which even makepkg devs will throw the towel and finally admit that downloading several GB of data only to checkout 100MB of relevant data is incredible waste of bandwidth, storage space and time :)
Comment by Eli Schwartz (eschwartz) - Tuesday, 29 June 2021, 20:45 GMT
This is not the right place to discuss whether makepkg should implement some changed behavior. Stick to discussing the actual ticket.
Comment by Emil (xexaxo) - Tuesday, 29 June 2021, 21:35 GMT
Yes the tarball is ~113MiB apologies. 5MiB was my abysmal internet connection earlier today.

In case it matters, makepkg cannot use shallow clone since that will not fetch the signed tag, hence gpg verify-tag will fail.
Comment by Morten Linderud (Foxboron) - Tuesday, 29 June 2021, 21:43 GMT
The issue is that heftig has said multiple times that this is the easiest option for them to maintain the kernel. The bandwidth savings and tarball size are all moot point, they don't make development and maintaining the kernel easier.
Comment by Emil (xexaxo) - Tuesday, 29 June 2021, 23:48 GMT
Perhaps I'm missing something but following the hardened [2] approach seems perfectly trivial, does it not?

It is also using a github repo with full kernel tree, although a signed patches tarball is also present used.
Off the top of my head - that can be trivially scripted, from tarball creation, signing and upload to github.

If anthraxx doesn't have a script (or cannot share it for whatever reason) I'm happy to take prep one.