[opensuse] Is it possible to update Tumbleweed to a less-than-current version?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I've been using Tumbleweed for several months now, and love it. One thing that I've been curious about though is -- let's say that I'm on 20171107, and the most recent is 20171114, but there was a release on 20171110. Is it possible to upgrade from 1107 to 1110, when 1114 is the most recent? I guess a way to be cutting edge without being totally bleeding edge? Chris -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAloMWrIACgkQQ1nEo4DF CIVv9gf/bEsbUgObLJHYM9wLuKPXBEpjNHUYVdmEEnTRQ+Z+TYfCNgG2krGvHLbi vJBWPVcoSg+71qXFKFEz/fIUKcJaKRHL9GZg4I8XPhGOOhyENc3iGsWmhQmVfqta CJuK82d7fMKCzizhhT7YAg34VNGRxfMJyIhY+u+s58VM/6XdlnnXsyvzsPpuolJT uLMluCMsucuZX2c3jzOz4pKqN3BZjyxiN5mK7aRoW5ghresBmJsHdGjQX5p8Q+Wq WeJHYIVpCwqj85mZumZQuJfUU5315SsiqLMrVRzNf2Mcu4O54wdZRlOc7QnV1gjU MAPyQhU9W2D7CAJgIswVvYjwVHZ7lg== =bF+q -----END PGP SIGNATURE-----
Op woensdag 15 november 2017 16:18:12 CET schreef Christopher Myers:
I've been using Tumbleweed for several months now, and love it. One thing that I've been curious about though is -- let's say that I'm on 20171107, and the most recent is 20171114, but there was a release on 20171110. Is it possible to upgrade from 1107 to 1110, when 1114 is the most recent? I guess a way to be cutting edge without being totally bleeding edge?
Chris
No, not AFAIK. The packages are in the TW distro repos, which are updated over and over again. No static situation. About the edges: since the appearance of openqa none of the edges could be called bleeding :D -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15 November 2017 at 17:02, Knurpht - Gertjan Lettink <knurpht@opensuse.org> wrote:
Op woensdag 15 november 2017 16:18:12 CET schreef Christopher Myers:
I've been using Tumbleweed for several months now, and love it. One thing that I've been curious about though is -- let's say that I'm on 20171107, and the most recent is 20171114, but there was a release on 20171110. Is it possible to upgrade from 1107 to 1110, when 1114 is the most recent? I guess a way to be cutting edge without being totally bleeding edge?
Chris
No, not AFAIK. The packages are in the TW distro repos, which are updated over and over again. No static situation. About the edges: since the appearance of openqa none of the edges could be called bleeding :D
Indeed - in fact there are multiple ways of thinking about it Option A) is the pessimistic "All snapshots are equally risky" theory. This philosophy suggests that there is just as much chance that yesterdays Tumbleweed snapshot will be broken as todays or Option B) the "we are doing a good job fixing things" theory. This suggests there is more chance that yesterdays Tumbleweed snapshot was more broken than todays. Either way justifies Tumbleweed's current "we only need one snapshot in the repos" approach and runs counter to the suggestion that somehow choosing some older snapshot is possibly going to be more 'stable' Old snapshots are old, not more stable, nor more reliable, nor more secure (we don't patch old snapshots) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2017-11-15 at 17:19 +0100, Richard Brown wrote:
On 15 November 2017 at 17:02, Knurpht - Gertjan Lettink <knurpht@opensuse.org> wrote:
Op woensdag 15 november 2017 16:18:12 CET schreef Christopher Myers:
I've been using Tumbleweed for several months now, and love it. One thing that I've been curious about though is -- let's say that I'm on 20171107, and the most recent is 20171114, but there was a release on 20171110. Is it possible to upgrade from 1107 to 1110, when 1114 is the most recent? I guess a way to be cutting edge without being totally bleeding edge?
Chris
No, not AFAIK. The packages are in the TW distro repos, which are updated over and over again. No static situation. About the edges: since the appearance of openqa none of the edges could be called bleeding :D
Indeed - in fact there are multiple ways of thinking about it
Option A) is the pessimistic "All snapshots are equally risky" theory. This philosophy suggests that there is just as much chance that yesterdays Tumbleweed snapshot will be broken as todays
or
Option B) the "we are doing a good job fixing things" theory. This suggests there is more chance that yesterdays Tumbleweed snapshot was more broken than todays.
Either way justifies Tumbleweed's current "we only need one snapshot in the repos" approach and runs counter to the suggestion that somehow choosing some older snapshot is possibly going to be more 'stable'
Old snapshots are old, not more stable, nor more reliable, nor more secure (we don't patch old snapshots)
Cool, makes sense :) So far I haven't had too many troubles, but since this is my work laptop, I'd kind of hoped to be able to hold off updates for a few days just to be safe if possible. But since it's not, oh well, that's part of the learning experience :) -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAloMg9oACgkQQ1nEo4DF CIUu0wf+P64BfFQ3Iy7YSIYpfDIS5+m/iitmB8FTwVgyrGzDbUBfFZjaPNUhXmkO YKS4BTiopKQcuJ4cOqkOHQOzJcBPZx8NH3RtnoutmiZfOZ7WdNvPOzhm9BZK9ZOz 6ZiNEI7InAte6Ksf7JT6nb+q+UVa6JLccmo7q1FAY2qyTJzuD5tYXZWGRX7kfY3I iJXVEVE6u9YgACeVXjbk0QTv6d3l66xSxaeqIDxh4XZF325ubP+3sHBqwCBb3mxr MrF9dCYeGFbWHyTgCJPaLMQQFcQbFov6FWjKJekIyaLLAFbvff/7jXBvsiXbMq2E N9O3S7nfG7fK48AX5mJUnsYeqKGcpQ== =Fqj4 -----END PGP SIGNATURE-----
On 11/15/2017 10:13 AM, Christopher Myers wrote:
I'd kind of hoped to be able to hold off updates for a few days just to be safe if possible. But since it's not, oh well, that's part of the learning experience
You don't have to run the auto-updater. I often shut that down, in when traveling, preparing for a new software release, or working on some deadline where I don't want any risk. Seldom for more than a month. Every Rolling Release has this "we are infallible" mind set till they get their first big humbling and humiliating majorly horked up update. Happened to Arch. Happened to Manjaro. Happened to Gentoo. Happened to Sabayon. Tumbleweed isn't a true rolling release, its sort of a peudo-rolling distribution based on a cyclical distribution, so it might be somewhat less prone to this problem. -- After all is said and done, more is said than done.
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <cmyers@millikin.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 2017-11-15 at 17:19 +0100, Richard Brown wrote:
On 15 November 2017 at 17:02, Knurpht - Gertjan Lettink <knurpht@opensuse.org> wrote:
Op woensdag 15 november 2017 16:18:12 CET schreef Christopher Myers:
I've been using Tumbleweed for several months now, and love it. One thing that I've been curious about though is -- let's say that I'm on 20171107, and the most recent is 20171114, but there was a release on 20171110. Is it possible to upgrade from 1107 to 1110, when 1114 is the most recent? I guess a way to be cutting edge without being totally bleeding edge?
Chris
No, not AFAIK. The packages are in the TW distro repos, which are updated over and over again. No static situation. About the edges: since the appearance of openqa none of the edges could be called bleeding :D
Indeed - in fact there are multiple ways of thinking about it
Option A) is the pessimistic "All snapshots are equally risky" theory. This philosophy suggests that there is just as much chance that yesterdays Tumbleweed snapshot will be broken as todays
or
Option B) the "we are doing a good job fixing things" theory. This suggests there is more chance that yesterdays Tumbleweed snapshot was more broken than todays.
Either way justifies Tumbleweed's current "we only need one snapshot in the repos" approach and runs counter to the suggestion that somehow choosing some older snapshot is possibly going to be more 'stable'
Old snapshots are old, not more stable, nor more reliable, nor more secure (we don't patch old snapshots)
Cool, makes sense :) So far I haven't had too many troubles, but since this is my work laptop, I'd kind of hoped to be able to hold off updates for a few days just to be safe if possible. But since it's not, oh well, that's part of the learning experience :)
In theory it would be simple to add a new zypper command to support: # zypper dup --download-only (this works today) watch mailing list for 2 days, no problems seen # zypper dup --cache-only ======= I don't run Tumbleweed in production, so I won't be the implementer. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Greg Freemyer <greg.freemyer@gmail.com> [11-15-17 13:44]:
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <cmyers@millikin.edu> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 2017-11-15 at 17:19 +0100, Richard Brown wrote:
On 15 November 2017 at 17:02, Knurpht - Gertjan Lettink <knurpht@opensuse.org> wrote:
Op woensdag 15 november 2017 16:18:12 CET schreef Christopher Myers:
I've been using Tumbleweed for several months now, and love it. One thing that I've been curious about though is -- let's say that I'm on 20171107, and the most recent is 20171114, but there was a release on 20171110. Is it possible to upgrade from 1107 to 1110, when 1114 is the most recent? I guess a way to be cutting edge without being totally bleeding edge?
Chris
No, not AFAIK. The packages are in the TW distro repos, which are updated over and over again. No static situation. About the edges: since the appearance of openqa none of the edges could be called bleeding :D
Indeed - in fact there are multiple ways of thinking about it
Option A) is the pessimistic "All snapshots are equally risky" theory. This philosophy suggests that there is just as much chance that yesterdays Tumbleweed snapshot will be broken as todays
or
Option B) the "we are doing a good job fixing things" theory. This suggests there is more chance that yesterdays Tumbleweed snapshot was more broken than todays.
Either way justifies Tumbleweed's current "we only need one snapshot in the repos" approach and runs counter to the suggestion that somehow choosing some older snapshot is possibly going to be more 'stable'
Old snapshots are old, not more stable, nor more reliable, nor more secure (we don't patch old snapshots)
Cool, makes sense :) So far I haven't had too many troubles, but since this is my work laptop, I'd kind of hoped to be able to hold off updates for a few days just to be safe if possible. But since it's not, oh well, that's part of the learning experience :)
In theory it would be simple to add a new zypper command to support:
# zypper dup --download-only (this works today)
watch mailing list for 2 days, no problems seen
# zypper dup --cache-only
======= I don't run Tumbleweed in production, so I won't be the implementer.
I do, but ... zypper -vv dup --cache-only Unknown option '--cache-only' is that something verry new? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-15 at 16:15 -0500, Patrick Shanahan wrote:
* Greg Freemyer <> [11-15-17 13:44]:
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <> wrote:
...
In theory it would be simple to add a new zypper command to support:
# zypper dup --download-only (this works today)
watch mailing list for 2 days, no problems seen
# zypper dup --cache-only
======= I don't run Tumbleweed in production, so I won't be the implementer.
I do, but ... zypper -vv dup --cache-only Unknown option '--cache-only'
is that something verry new?
He is proposing that new option :-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloMsPkACgkQtTMYHG2NR9XvPgCeIe7WcsJAws8n3X0YSvPpYt9R QHYAoJiWsQCC/o4XGUAH0eaCz1JWkUsD =Xa5U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, 2017-11-15 at 22:26 +0100, Carlos E. R. wrote:
On Wednesday, 2017-11-15 at 16:15 -0500, Patrick Shanahan wrote:
* Greg Freemyer <> [11-15-17 13:44]:
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <> wrote:
...
In theory it would be simple to add a new zypper command to support:
# zypper dup --download-only (this works today)
watch mailing list for 2 days, no problems seen
# zypper dup --cache-only
======= I don't run Tumbleweed in production, so I won't be the implementer.
I do, but ... zypper -vv dup --cache-only Unknown option '--cache-only'
is that something verry new?
He is proposing that new option :-)
Out of curiosity, are you proposing that running zypper dup --cache-only would run the zypper dup from the cache, after having done a zypper dup --download-only a few days prior? If so, that could be a cool feature. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAloMuMkACgkQQ1nEo4DF CIWTFggAhG3ce72jxeOV67+6Dm5F3D4aT5g1lSyi5UxKkasvyP0X46cAj7Upkzgi cvfvsSPT0tLdooUR6+XU3DRPIZ7+eGmvRsT0gmlMI9N8njIjiOQYMATPZtBmBQQ0 vlJ+gi8Otr0gL+V3W7WicSFS51m26UyBHugKoHE0mNXZAoz+OEuYMoid4jjbyDDd b2LDOT5vRkjCKCOiYAWs5H76nr+2K16eqztMh29nQS30LDwjwkeLj4ZWy+AiM7RC YGXsu7CD8+oP9BNWeLiCYe/Q2NMp/t/Ch+ZwWHS9H7KP8UZTG1giaGNnwCUJNMDQ aMpVGCuVYdaOkaQ6Ho6mFDWVFHnzig== =5oky -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-15 at 21:59 -0000, Christopher Myers wrote:
On Wed, 2017-11-15 at 22:26 +0100, Carlos E. R. wrote:
On Wednesday, 2017-11-15 at 16:15 -0500, Patrick Shanahan wrote:
* Greg Freemyer <> [11-15-17 13:44]:
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <> wrote:
...
In theory it would be simple to add a new zypper command to support:
# zypper dup --download-only (this works today)
watch mailing list for 2 days, no problems seen
# zypper dup --cache-only
======= I don't run Tumbleweed in production, so I won't be the implementer.
I do, but ... zypper -vv dup --cache-only Unknown option '--cache-only'
is that something verry new?
He is proposing that new option :-)
Out of curiosity, are you proposing that running
zypper dup --cache-only
would run the zypper dup from the cache, after having done a
zypper dup --download-only
a few days prior? If so, that could be a cool feature.
Not me, but he :-) But he also said he would not be implementing that option himself, as he doesn't use TW in production. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloMvXwACgkQtTMYHG2NR9UsfACdGAIzvAUkVMR29mewswPNKwqu mpcAniKrpK+u644QPt1LvJkWnJoMCRxa =DOC8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Christopher Myers <cmyers@millikin.edu> [11-15-17 17:02]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, 2017-11-15 at 22:26 +0100, Carlos E. R. wrote:
On Wednesday, 2017-11-15 at 16:15 -0500, Patrick Shanahan wrote:
* Greg Freemyer <> [11-15-17 13:44]:
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <> wrote:
...
In theory it would be simple to add a new zypper command to support:
# zypper dup --download-only (this works today)
watch mailing list for 2 days, no problems seen
# zypper dup --cache-only
======= I don't run Tumbleweed in production, so I won't be the implementer.
I do, but ... zypper -vv dup --cache-only Unknown option '--cache-only'
is that something verry new?
He is proposing that new option :-)
Out of curiosity, are you proposing that running
zypper dup --cache-only
would run the zypper dup from the cache, after having done a
zypper dup --download-only
a few days prior? If so, that could be a cool feature. -----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAloMuMkACgkQQ1nEo4DF CIWTFggAhG3ce72jxeOV67+6Dm5F3D4aT5g1lSyi5UxKkasvyP0X46cAj7Upkzgi cvfvsSPT0tLdooUR6+XU3DRPIZ7+eGmvRsT0gmlMI9N8njIjiOQYMATPZtBmBQQ0 vlJ+gi8Otr0gL+V3W7WicSFS51m26UyBHugKoHE0mNXZAoz+OEuYMoid4jjbyDDd b2LDOT5vRkjCKCOiYAWs5H76nr+2K16eqztMh29nQS30LDwjwkeLj4ZWy+AiM7RC YGXsu7CD8+oP9BNWeLiCYe/Q2NMp/t/Ch+ZwWHS9H7KP8UZTG1giaGNnwCUJNMDQ aMpVGCuVYdaOkaQ6Ho6mFDWVFHnzig== =5oky -----END PGP SIGNATURE-----
then as I do set autorefresh=0 in repo zypper ref && zypper -v dup -d --no-r --no-a && zypper -v dup --no-r --no-a this would mimic the action desired by --cache-only I have utilized this method for several years now -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Greg Freemyer Advances are made by answering questions. Discoveries are made by questioning answers. — Bernard Haisch On Wed, Nov 15, 2017 at 4:59 PM, Christopher Myers <cmyers@millikin.edu> wrote:
On Wed, 2017-11-15 at 22:26 +0100, Carlos E. R. wrote:
On Wednesday, 2017-11-15 at 16:15 -0500, Patrick Shanahan wrote:
* Greg Freemyer <> [11-15-17 13:44]:
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <> wrote:
In theory it would be simple to add a new zypper command to support:
# zypper dup --download-only (this works today)
watch mailing list for 2 days, no problems seen
# zypper dup --cache-only
======= I don't run Tumbleweed in production, so I won't be the implementer.
I do, but ... zypper -vv dup --cache-only Unknown option '--cache-only'
is that something verry new?
He is proposing that new option :-)
Out of curiosity, are you proposing that running
zypper dup --cache-only
would run the zypper dup from the cache, after having done a
zypper dup --download-only
a few days prior? If so, that could be a cool feature.
That indeed was my proposal. It seems like it's a straight forward feature to add. Maybe the arg should be "--install-RPMs-from-cache-only" But, as I said I won't be the implementer. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 15 Nov 2017 13:40:52 -0500 Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Wed, Nov 15, 2017 at 1:13 PM, Christopher Myers <cmyers@millikin.edu> wrote:
Cool, makes sense :) So far I haven't had too many troubles, but since this is my work laptop, I'd kind of hoped to be able to hold off updates for a few days just to be safe if possible. But since it's not, oh well, that's part of the learning experience :)
In theory it would be simple to add a new zypper command to support:
# zypper dup --download-only (this works today)
watch mailing list for 2 days, no problems seen
# zypper dup --cache-only
Isn't this the primary use case for btrfs? If I ran tumbleweed, which I don't because I prefer stability, then surely the ability to apply an update and then revoke it if I didn't like it would be a very strong motivation to grow to love btrfs. It's another way of skinning this cat. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
-----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-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2017-11-17 at 23:27 +0100, Bjoern Voigt wrote:
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:
+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.
Well, it is for that reason that I avoid TW... Not only that, of course. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloQQxEACgkQtTMYHG2NR9Wx1gCfetljg19yE8n9rjkF+gMXo8PI AIkAoIX/FJ/cHbCuwpyvE1vFRawtVBhl =aQ4V -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, 2017-11-18 at 15:26 +0100, Carlos E. R. wrote:
On Friday, 2017-11-17 at 23:27 +0100, Bjoern Voigt wrote:
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:
+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.
Well, it is for that reason that I avoid TW... Not only that, of course.
To be perfectly honest, the only reason I went with Tumbleweed is because openSuSE doesn't have an LTS release, and my hardware at work always lives longer than the openSuSE releases. I know that I could do an in-place upgrade, which is basically sort of what doing the TWeed releases does, but historically doing updates like oS 13.1 ... 13.2 ... Leap haven't always gone well, and definitely takes longer than a "zypper dup". I toyed with the idea of doing Debian since they have an LTS version, but I prefer it for servers moreso than desktops (although my laptop at home runs Debian.) -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAloR63cACgkQQ1nEo4DF CIVwfQf/TkyborBaCgp7MOnhS4BVzqHvy2VMVMsrG1WvqYEEJ8H6gTYi073Nc5ya AYG5fql/nHFg7uB5awbBqUktD1UbgRDQ8Cp5S6Dj+z+ErD1y4IiP/yT0TBmb/Lrn AiR7pwuUIwMQM46W6qvWpY6CA2VWO57cHSpqx9XfluUmRymzke+wRn8EiW2wP+YB pCTk8oZ38JzNt9EETUvVQQnSXVAjXZcIjrd1yY35V9tOF23dsW8tZVk3M1GSSy9T HiyPaEILoiyCQgPmHwntS1IZE2BXAQYn4Q+T47dTBl+v7jS31z/dwIdORUodAJqS 3xyCdC9GULLXqhlcKvnOD/Nm4s3jDA== =aqTg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-11-19 at 20:37 -0000, Christopher Myers wrote:
On Sat, 2017-11-18 at 15:26 +0100, Carlos E. R. wrote:
On Friday, 2017-11-17 at 23:27 +0100, Bjoern Voigt wrote:
Christopher Myers schrieb:
On Fri, 2017-11-17 at 15:14 +0100, Richard Brown wrote:
On 17 November 2017 at 14:39, Bjoern Voigt <> wrote:
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.
Well, it is for that reason that I avoid TW... Not only that, of course.
To be perfectly honest, the only reason I went with Tumbleweed is because openSuSE doesn't have an LTS release, and my hardware at work always lives longer than the openSuSE releases. I know that I could do an in-place upgrade, which is basically sort of what doing the TWeed releases does, but historically doing updates like oS 13.1 ... 13.2 ... Leap haven't always gone well, and definitely takes longer than a "zypper dup". I toyed with the idea of doing Debian since they have an LTS version, but I prefer it for servers moreso than desktops (although my laptop at home runs Debian.)
Well, but going with TW you get about 300 dups/yr. I have always done offline system upgrades to all my systems since 1998, and they mostly go well. In Leap the upgrade was easier than on anything earlier. The upgrade to 15.0 may have issues. I only have to worry about once a year, and there is some documentation about abrupt changes, like would be this one with mysql. And being a once a year thing, I do a full backup just in case things go wrong, so that I can fully revert, and try again or do something differently. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloR+s4ACgkQtTMYHG2NR9U4fQCeMMHhp/UNWpoXx0lPo2swRBP8 hn4AnAgpQq5JjjwY57bx4nSu9R+htcX6 =OSbx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Bjoern Voigt -
Carlos E. R. -
Christopher Myers -
Dave Howorth -
Greg Freemyer -
John Andersen -
Knurpht - Gertjan Lettink -
Patrick Shanahan -
Richard Brown