On 17 November 2017 at 14:39, Bjoern Voigt <bjoernv@arcor.de> wrote:
I understand the request.
I see that a snapshot from yesterday has no better quality on average then the snapshot from today. Anyway, there are exceptions.
If I broke my system today (and have no time or knowledge to fix it myself) I may have the wish to roll-back to the version from yesterday. If I know, which package broke my system, I have good chances, that I find the previous package version still on the mirrors or on my local Zypp cache (if keeppackages=1 for the repository).
If I don't know, which of hundreds of update packages causes the problem, I may wish to roll-back all packages until I hear the news, that someone fixed the package.
Users with Btrfs can easily roll-back their systems. Users with other filesystems have much more trouble to roll-back the system packages from a daily backup (if available) without loosing the data changes in /home, /var etc.
My implementation idea: 1) define a minimum time how long old packages will still exist on the mirrors 2) create directories on the mirrors which contain the daily repository metadata 3) do the necessary changes, so that Zypp can use repository metadata from a given sub-directory (name: the date) and for user-friendly downgrading of packages.
Probably 3) is the most difficult part. Also it's clear, that Btrfs roll-backs are still better in some situations, especially, if packages are not prepared for downgrades.
Greetings, Björn
And how would your suggestion deal with the fact that the vast majority of the time that rolling back packages using rpm results in a *more* broken system because the old versions of software no longer work with the databases/configurations/etc which were upgraded as part of the upgrade to the broken package versions? This is why we recommend btrfs, this is why doing the rollback and worrying about that stuff makes sense at the btrfs level, because btrfs lets us record the system_state, not relying on the package_state which is never going to be a complete picture of the actual status of all the packages on a machine. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org