On Wed, 22 Nov 2017, Jimmy Berry wrote:
Some of you may remember over a year ago when I proposed the concept of Tumbleweed Snapshots  and later the prototype that I provided . Today I would like to announce hosting for the snapshots, that is not inside my house :), and ready to use!
For those not familiar with the concept I will describe it in the form to which it has evolved.
Tumbleweed, being a rolling distribution, is constantly changing and packages are constantly being rebuilt against one another and updating requirements. As such it becomes necessary to update even when undesirable. For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday.
So the issue is that somebody (for example packagekit) does a refresh on the repo file and not that the mirrors purge old rpms referenced from older meta data, right? To me it sounds you want to "pin" metadata instead? What happens to security updates in this case?
I suppose the way we organize repository meta-data is less than optimal here. With updated metadata I suppose you can't even do a zypper in glibc-2.22-4.9.1.x86_64 with a version from an earlier snapshot.
That is, we'd need repo metadata that covers the full state of the download area, thus reflecting what you can actually install? And zypper having multiple version choices for a specific package could be asked to do a "minimal" install that requires the least number of packages to update but by default would prefer the newest version.
Such repo data might be huge of course and we might be too aggressive in pruning old binary rpms from the download area and thus making old repodata invalid fast.
Disclaimer: I didn't look into what you actually do implementation wise.