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 [1] and later the prototype that I provided [2]. 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.
Richard.
--
Richard Biener