<div dir="ltr">Hello,<div><br></div><div>This is not a concern for <a href="http://archlinux.mirror.digitalpacific.com.au">archlinux.mirror.digitalpacific.com.au</a><br></div><div><br></div><div>I think it should be mandatory for Tier1 mirrors to support whatever the Arch community requires, although Tier2 should be opt-in.</div><div><br></div><div>Thanks,</div><div>Matthew.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 6, 2020 at 5:58 AM Eli Schwartz <<a href="mailto:eschwartz@archlinux.org">eschwartz@archlinux.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If Arch Linux were to add repositories containing split debug packages<br>
for all our x86_64 packages, this would obviously add a fair amount of<br>
space to the mirror requirements. It could possibly double or triple the<br>
size taken by non-data packages. I don't have real-world numbers for how<br>
much space it would take up, but I do have some comparisons.<br>
<br>
For my custom repo as a sample, which I do upload debug packages for, I<br>
am using 2.9Gi of space, and 1.7Gi comes from debug packages.<br>
<br>
On the other side of things, our biggest 2 official packages are cuda,<br>
4137.96 MiB of proprietary blobs that aren't currently stripped and<br>
therefore even if we did split it into a debug package it wouldn't<br>
increase space usage at all, and kicad-library-3d, 5171.97 MiB of pure<br>
data in /usr/share, which is not eligible for debug packages anyway.<br>
<br>
A naive list of packages which would probably generate debug packages:<br>
<br>
$ expac -H M '%m %n %a' | grep -v 'any$' | sort --human-numeric-sort<br>
[...]<br>
1109.50 MiB emscripten x86_64<br>
1136.27 MiB python-tensorflow x86_64<br>
1145.23 MiB python-tensorflow-opt x86_64<br>
1286.69 MiB python-pytorch-cuda x86_64<br>
1289.44 MiB python-pytorch-opt-cuda x86_64<br>
1518.42 MiB ghc-static x86_64<br>
2589.23 MiB python-tensorflow-cuda x86_64<br>
2597.38 MiB python-tensorflow-opt-cuda x86_64<br>
3757.68 MiB tensorflow-cuda x86_64<br>
3765.75 MiB tensorflow-opt-cuda x86_64<br>
4137.96 MiB cuda x86_64<br>
<br>
(Basically all of the really big stuff is tensorflow/cuda/machine<br>
learning bits. We could selectively disable debug packages for two<br>
PKGBUILDs and avoid all the worst offenders, if we needed to. heh.)<br>
<br>
Packages which definitely would not (there's some big, high-profile<br>
packages here, and my custom repo doesn't reflect this sort of spread at<br>
all):<br>
<br>
$ expac -H M '%m %n %a' | grep -v 'any$' | sort --human-numeric-sort<br>
[...]<br>
1202.02 MiB texlive-fontsextra any<br>
1307.98 MiB texlive-fontsextra any<br>
2006.67 MiB 0ad-data any<br>
3112.39 MiB nltk-data any<br>
5171.97 MiB kicad-library-3d any<br>
<br>
...<br>
<br>
Anyway, providing these symbols would be generally desirable for users,<br>
and ideally it would work opt-out to make it easier for users to get<br>
access to them. It's something we've generally wanted to do, see for<br>
example <a href="https://bugs.archlinux.org/task/38755" rel="noreferrer" target="_blank">https://bugs.archlinux.org/task/38755</a><br>
And it's possible we may actually, at long last, get around to<br>
implementing this.<br>
<br>
So, question to mirror admins: if Arch was to add debug repositories,<br>
would you be okay syncing them? And should it be opt-in or opt out?<br>
<br>
The answers to these questions will influence the direction I will take<br>
in trying to devise a satisfactory resolution to this outstanding<br>
infrastructure request. So I would love to get some input from the<br>
people who would be affected by such a change.<br>
<br>
-- <br>
Eli Schwartz<br>
Bug Wrangler and Trusted User<br>
<br>
</blockquote></div>