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 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. 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