Christopher Myers schrieb:
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. +1
I am also not sure, if Btrfs roll-backs are always working as expected. One example: As MySQL was dropped from TW, "zypper dup" installed MariaDB as a MySQL replacement. I didn't know that, otherwise I had locked the MySQL packages. My system broke because I used MySQL specific options in /etc/my.cnf. Also I had no interest to upgrade to MariaDB on this computer. So I downloaded the old MySQL packages from TW mirrors (and later the source-RPMS from Leap 42.3) and installed MySQL again. After downgrading to MySQL I got some problems with my /var/lib/mysql data, caused by the MariaDB upgrade scripts, which could be handled manually. To summarize, I had problems with upgrading and downgrading packages. But how could Btrfs help here? If the Btrfs roll-back reverts /usr/*/mysql*, /var/lib/mysql and /etc together, then I loose updated data in /var/lib/mysql - modified between the upgrade and the downgrade. If the roll-back leaves /var/lib/mysql intact, then the roll-back does not work as expected. Personally I would prefer announcements which warn the user before they may run into known problems. Sometimes such warnings can be found in the mailing lists. FreeBSD uses a file called /usr/ports/UPDATING as part of the ports collection for this. If contains notes like this sorted by time: 20170928: AFFECTS: users of security/courier-authlib and its modules AUTHOR: madpilot@FreeBSD.org The affected ports have been modified to follow the upstream suggested best practice to use the sysconftool on installation. Please make sure your configuration files include all the comments that tool uses to correctly update the configuration on update. You can use the ".sample" or ".dist" files as templates for missing comments if needed. Greetings, Björn -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org