-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, 2017-11-17 at 15:14 +0100, Richard Brown wrote:
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 be honest, I'm scared of BTRFS. I don't trust it. I've seen too many threads of "my disk is full and I have no idea why or how to fix it" to risk that for my laptop at this point. Plus, the disk layout looks so kludgy and unmanageable, with all of the subvolumes and such. I think that once BTRFS matures more and these kinks work out, I'll play around with it. And maybe I'll love it so much that I bemoan my feet-dragging. In the interim though, I'm sticking with XFS and EXT4, because they're time-tested and just plain work. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAloPPLoACgkQQ1nEo4DF CIUkZwf/b04fFi0lThZHp8n3/L7H0ZVjoBsKEpX5ivZbcfFTycQhdX8Qj0+iv+E2 eknbBcKp8fzZYqerfjDUnnNxAVvoFhN9cbzYDKi0am3ZWsjImzwxHlIgbI+F7Sx/ ZQi8MLpGYlmMAXFtprW0lwXRx2OY4+pke00O+XfGzKoCc9nUVgoNza9E34RnxEmA Sa4hv0lzfqitWShSXJ9RkqCwZ3g56L8FvJprMJ4aWOvpKkLfQcvZHptBCccKVgcF r5RY58+oyR6bfhtXV/yg2Og1PQTUI5QOBZ+g7dM+liWhMU2DI+p5dmZs7uIq7fiS 06M+6qo0fU76qcuRCH2wuruaIqX/hQ== =mhm+ -----END PGP SIGNATURE-----