On Thu, Nov 23, 2017 at 3:15 AM, Richard Biener email@example.com wrote:
On Wed, 22 Nov 2017, Jimmy Berry wrote: 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?
Pinning metadata is not terribly useful if the referenced rpms are not available in the remote repo. Security updates remain unchanged. The update repo (for urgent security fixes) is already iffy depending on which snapshot you have installed and it is not snapshotted in anyway by my tool. As such the behavior should be the same as default setup.
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.
Indeed. Having to download such a large amount of meta data, depending on how far back is available just to see the current state seems rather suboptimal. Creating the "merged metadata" and then managing the rpms based on it does not seem beneficial. From the user stand point they simply want to install the new package that was built for their current install. If they want everything updated then they should update.
This implementation preserves full meta data sets for each snapshot and keeps all the relevant rpms. As such you simply point the repo URL at the snapshot you have installed or want to install and zypper operates normally. The default setup (depending on what changes are in newer snapshots) is basically like running Leap 42.3 with your repos pointed at 15.0 and installing kate. That may or may not end well. The expected behavior there would be to dup to 15.0 and then install kate. Rather than expect that users dup every day this allows users to update at their own pace, but still install things as needed.
Your idea about asking zypper to install with "minimal change" seems like a similar concept, but would require further investigation and implementation. This approach would appear simpler and operates transparently as if they are "mini-ephemeral-static distros" which are just historical Tumbleweed snapshots. Purely to allow a user to keep using the snapshot which they have installed since installing new packages essentially built for a "different" distro is less than ideal. Basically, users are in two modes: I want to update to latest, or I just want to install this new thing. This allows those mental modes to map to reality just like they did prior to rolling release.
Depending on the way the rpm requirements are setup I've seen installing a new application trigger partial qt or kde updates that create an unusable desktop (even X fail to start). Short of some serious changes to spec file policies and tooling this seems like the only sane solution.