On Fri, Jun 11, 2021 at 12:23 PM Carl George <carl at redhat.com> wrote: > > We don't know what our runway on disk space will be either. > Hardlinking helps lots but also makes estimating harder. Since > announcing that change, we haven't removed any packages for space > constraints. > > Honestly I question the value of writing a dnf plugin to pick packages > out of the old composes, because I expect most if not all package > versions will be kept going forward. The space constraint comment was You may want to consider the impact to mirrors and come up with a retention policy that helps them a bit. We've built 313 kernel packages so far in RHEL 8 (actually more, but at least 313 starting from 4.18.0). Using an "all versions" approach and some very very basic math, that's ~330MB of binary packages per architecture per kernel SRPM, so 1.3G per kernel build * 313 builds ~= 403GB just for the kernels, not including sources or debuginfo. That's a lot of data for the mirrors to keep around for relatively little gain. > mainly me setting expectations that if we do happen to run out of > space, we reserve the right to remove the oldest content to reclaim > space. As a practical example, let's say you notice a regression in a > kernel update, and we're shipping 10 kernel package versions. What is > the likelihood you will need the 10th oldest kernel to verify when the > regression happened? Unless you've gone a long time without updating, > having the last 2 or 3 kernels is probably sufficient. Right. I'd suggest defining a policy that is approximately N-5 versions and adjust from there if needed. josh > On Fri, Jun 11, 2021 at 10:06 AM Laura Hild <lsh at jlab.org> wrote: > > > > > I was looking to be able to go back more than one version and it seem > > > like composes could allow doing that? Not all issues are discovered > > > right away and may already exist in the previous version. > > > > I did this just yesterday, going back to systemd-239-43. I noticed my > > problem on RHEL, which jumped from 41 to 45, but I am potentially able > > to write a better ticket by being able to reproduce it in Stream, if I > > can go back more than one version. > > > > Could it make sense to base what versions are made available in Stream > > on what's between versions in RHEL? I have no concept of the limits on > > space though, particularly for mirrors. > > > > -Laura > > > > _______________________________________________ > > CentOS-devel mailing list > > CentOS-devel at centos.org > > https://lists.centos.org/mailman/listinfo/centos-devel > > > > > -- > Carl George > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel