Tumbleweed, being a rolling distribution, is constantly changing and packages are constantly being rebuilt against one another and updating requirements. As such it becomes necessary to update even when undesirable. For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday.
If a remote repository containing historical snapshots was available one could simply install the application and perhaps the handful of new dependencies it requires rather than having to update the entire system. This provides one with the benefits of a rolling distribution without requiring the constant change. A week later when a new kernel and DRM stack provides an exciting feature it is still easy to update everything and be running the latest code, but the user is not interrupted by having to update when it should not be necessary.
From another angle, the capabilities of rollback using snapper and btrfs are widely advertised, but the cumbersome and rather unusable state in which a user is left is not commonly discussed. If for example a kernel and/or network manager update completely break network functionality for certain users they can rollback, but then what. As they wait for a fix their installation falls further behind and with that it becomes less and less likely that installing a new package will function properly.
On a similar note, if one wanted to install debuginfo packages it is many times impossible without first updating that application and with it many of its dependencies.
Such historical snapshot repositories are available and a command line tool, built on libzypp changes, which eases usage. This talk will provide an introduction to the motivation behind this project, implementation, and usage. In addition the Tumbleweed snapshot review site will also be covered to aid users in utilizing Tumbleweed in a manor that suits them. In general this approach offers no downsides if one wishes to still update to every new snapshot or preferred to wait in order to ensure a usable system for getting work done.
The review site opens up the possibility to analyze and even predict the stability of releases. With this there is likely plenty of topics of discussion surrounding pushing it further.
- https://www.youtube.com/watch?v=CSXRreUjiIc
- http://release-tools.opensuse.org/2017/11/22/Tumbleweed-Snapshots.html
- http://review.tumbleweed.boombatower.com/
Tumbleweed, being a rolling distribution, is constantly changing and packages are constantly being rebuilt against one another and updating requirements. As such it becomes necessary to update even when undesirable. For example, one is running snapshot 17 and the next day snapshot 18 contains a QT update that rebuilt a large number of packages. When attempting to install an application that depends on QT one is greeted with an ugly unresolveable error. It is then necessary to run a full update, likely very large with many unrelated changes, in order to simply install an application as would have been possible yesterday.
If a remote repository containing historical snapshots was available one could simply install the application and perhaps the handful of new dependencies it requires rather than having to update the entire system. This provides one with the benefits of a rolling distribution without requiring the constant change. A week later when a new kernel and DRM stack provides an exciting feature it is still easy to update everything and be running the latest code, but the user is not interrupted by having to update when it should not be necessary.
From another angle, the capabilities of rollback using snapper and btrfs are widely advertised, but the cumbersome and rather unusable state in which a user is left is not commonly discussed. If for example a kernel and/or network manager update completely break network functionality for certain users they can rollback, but then what. As they wait for a fix their installation falls further behind and with that it becomes less and less likely that installing a new package will function properly.
On a similar note, if one wanted to install debuginfo packages it is many times impossible without first updating that application and with it many of its dependencies.
Such historical snapshot repositories are available and a command line tool, built on libzypp changes, which eases usage. This talk will provide an introduction to the motivation behind this project, implementation, and usage. In addition the Tumbleweed snapshot review site will also be covered to aid users in utilizing Tumbleweed in a manor that suits them. In general this approach offers no downsides if one wishes to still update to every new snapshot or preferred to wait in order to ensure a usable system for getting work done.
The review site opens up the possibility to analyze and even predict the stability of releases. With this there is likely plenty of topics of discussion surrounding pushing it further.
- https://www.youtube.com/watch?v=CSXRreUjiIc
- http://release-tools.opensuse.org/2017/11/22/Tumbleweed-Snapshots.html
- http://review.tumbleweed.boombatower.com/