[arch-mirrors] Possibility of adding debug repositories

Eli Schwartz eschwartz at archlinux.org
Fri Jun 12 18:18:30 UTC 2020


On 6/6/20 7:05 PM, Tyler Dence wrote:
> I (arlm.tyzoid.com) would prefer an opt-in solution. Such a method would
> allow us to evaluate in advance the storage requirements to make sure that
> we don't run out of storage space on the virtual disk.
> 
> How it's implemented with rsync is an open question. Would it exist as a
> new endpoint? If so, wouldn't it necessitate extra config on the
> apache/nginx side?
> 
> 
> On Sat, Jun 6, 2020, 6:37 PM Tails Hon1nbo <hon1nbo+mirror at hackingand.coffee>
> wrote:
> 
>> Hacking & Coffee would be interested, but make it a separate "opt-in"
>> dataset especially if it's unpredictable how much space it will take.
>> If suddenly enabled, and set to opt-out, I imagine some mirror clusters
>> would have a sudden, unexpected storage problem
The storage requirements should not sharply rise, unless we do a mass
rebuild that enables debug packages. I think a reasonable thing to do
from the packaging side of things is to rebuild some critical libraries,
but leave most packages to simply acquire debug packages whenever they
are rebuilt for other reasons.

We could also give advance notice, e.g. something along the lines of "we
will enable debug packages next month, make sure your disks can handle
irregular growth of up to XXX gb or set the following rsync exclusion in
advance and re-evaluate after the churn".

Would this be a reasonable way to handle it? It would have the advantage
of not requiring new rsync endpoints and server configs.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-mirrors/attachments/20200612/d3986a5b/attachment.sig>


More information about the arch-mirrors mailing list